Received: by 10.192.165.148 with SMTP id m20csp807683imm; Thu, 10 May 2018 00:32:38 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq0uoWcMk52+I6x1HLW3wwY8HSOIbA1q9mIk8wbQB2PoAjvMA92Uum7oTjY7MtkKFpzcGfe X-Received: by 2002:a65:590e:: with SMTP id f14-v6mr258423pgu.282.1525937558213; Thu, 10 May 2018 00:32:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525937558; cv=none; d=google.com; s=arc-20160816; b=MJ1Gb3+9AR8ig2BAPdHQXoWHaylhZh+xnAaiDFI5qc3PVGOoeW75YTTp6TyCU63QwF dpgWqFhHwQWt5N+X9nPgGqKqhhlPsi2Yjcybq0oFEXuFYLawIMgN4/YFXqmmxb16EV+O /67EvUL+gTYu27ct9uphajxtLscq67Mv0QBXnqO4oeTbohVfmCswqj95INoRnwD41uca 216dHOzCuWy0CLwKlAOO+bjLQ/dQZg0vTmSWvRFRn+KKUt2wFgZYauLAEq1tNBHs//dF fqqB1mV4XQindmgC/+1FPZvgfaBpbOG1Ghi6P9o35nfC1Z3rSEFfrtmEHEQ8f4n+koPI R33A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=Ko6ApFC1fkYms2nwY5s7XpXKWN+0k/F6HgEWS4bv4bY=; b=N0IvBPrKrysTyLNP0Clusws55rN2fZ86AKCemVtdiKqHcLtDeQZglp9XCGWV6HG5ng CAHViNkdnQ6ZBQ5jf9fkNBlkce4o3i4ZYftl9RqowCB8oSy+HPmdK7YMAPoY/zzJMND9 2zqB27xW86DLJiSa3aK/asLeBGziB1Cr3FJAWOWS0VWXhUGT2gBVpgpr0ucSps+Cavny 4VJybqKlNyCcwa55TV4K8CGNhKGNsQxw8+JoAIxcppbw1T+nOjSkSzArypxCVbMcvvyg uVd0xS+T9g60Oa1strHXRtxEF7hAik9nscB5rSYb7oWWwEu6eZX/+W7aIgkMgrsI39Sd XAdw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bb5-v6si201463plb.80.2018.05.10.00.32.23; Thu, 10 May 2018 00:32:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934517AbeEJHa5 (ORCPT + 99 others); Thu, 10 May 2018 03:30:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:49472 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934278AbeEJHa4 (ORCPT ); Thu, 10 May 2018 03:30:56 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3A263ACB6; Thu, 10 May 2018 07:30:55 +0000 (UTC) Date: Thu, 10 May 2018 09:30:54 +0200 From: Michal Hocko To: Ganapatrao Kulkarni Cc: Ganapatrao Kulkarni , Tony Luck , "Rafael J. Wysocki" , tiantao6@huawei.com, LKML , linux-acpi@vger.kernel.org Subject: Re: fd3e45436660 ("ACPI / NUMA: ia64: Parse all entries of SRAT memory affinity table") Message-ID: <20180510073054.GD32366@dhcp22.suse.cz> References: <20180411104832.GF23400@dhcp22.suse.cz> <20180509122454.GR32366@dhcp22.suse.cz> <20180509125611.GT32366@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 10-05-18 08:27:35, Ganapatrao Kulkarni wrote: > On Wed, May 9, 2018 at 6:26 PM, Michal Hocko wrote: > > On Wed 09-05-18 18:07:16, Ganapatrao Kulkarni wrote: > >> Hi Michal > >> > >> > >> On Wed, May 9, 2018 at 5:54 PM, Michal Hocko wrote: > >> > On Wed 11-04-18 12:48:32, Michal Hocko wrote: > >> >> Hi, > >> >> my attention was brought to the %subj commit and either I am missing > >> >> something or the patch is quite dubious. What is it actually trying to > >> >> fix? If a BIOS/FW provides more memblocks than the limit then we would > >> >> get misleading numa topology (numactl -H output) but is the situation > >> >> much better with it applied? Numa init code will refuse to init more > >> >> memblocks than the limit and falls back to dummy_numa_init (AFAICS) > >> >> which will break the topology again and numactl -H will have a > >> >> misleading output anyway. > >> > >> IIRC, the MEMBLOCK beyond max limit getting dropped from visible > >> memory(partial drop from a node). > >> this patch removed any upper limit on memblocks and allowed to parse > >> all entries of SRAT. > > > > Yeah I've understood that much. My question is, however, why do we care > > about parsing the NUMA topology when we fallback into a single NUMA node > > anyway? Or do I misunderstand the code? I do not have any platform with > > that many memblocks. > > IMHO, this fix is very much logical by removing the SRAT parsing restriction. > below is the crash log which made us to debug and eventually fix with > this patch. Ohh, I am not saying that the current code handles too many memblocks correctly. I just think that your fix is not correct or incomplete at least. Assuming that my understanding is correct which you haven't disputed yet. So can we focus on the proper solution now? Do we actually need the memblock restrictions? We do not need those for reserved memblocks so I do not see any real reason to simply remove the restriction altogether. Have you explored that option? -- Michal Hocko SUSE Labs