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:24:54 +0200 Message-ID: <20180509122454.GR32366@dhcp22.suse.cz> References: <20180411104832.GF23400@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20180411104832.GF23400@dhcp22.suse.cz> Sender: linux-kernel-owner@vger.kernel.org To: Ganapatrao Kulkarni Cc: Tony Luck , "Rafael J. Wysocki" , tiantao6@huawei.com, LKML , linux-acpi@vger.kernel.org List-Id: linux-acpi@vger.kernel.org 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. > > So why is the patch an improvement at all? ping? I would be tempted to simply revert the patch as a wrong fix. -- Michal Hocko SUSE Labs