On Wed 09-05-18 18:07:16, Ganapatrao Kulkarni wrote: > Hi Michal > > > On Wed, May 9, 2018 at 5:54 PM, Michal Hocko <mhocko@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
