From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: fd3e45436660 ("ACPI / NUMA: ia64: Parse all entries of SRAT memory affinity table") Date: Wed, 9 May 2018 14:56:11 +0200 Message-ID: <20180509125611.GT32366@dhcp22.suse.cz> References: <20180411104832.GF23400@dhcp22.suse.cz> <20180509122454.GR32366@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Ganapatrao Kulkarni Cc: Ganapatrao Kulkarni , Tony Luck , "Rafael J. Wysocki" , tiantao6@huawei.com, LKML , linux-acpi@vger.kernel.org List-Id: linux-acpi@vger.kernel.org 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. -- Michal Hocko SUSE Labs