Received: by 10.192.165.148 with SMTP id m20csp5486225imm; Wed, 9 May 2018 05:57:05 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrcGf7EkDYDRk0nPZqpaF+nEf42nbjgZ4++5zF1ZncTnas/fq417qfv3X550r+LdCqc+Evy X-Received: by 10.167.128.198 with SMTP id a6mr22491479pfn.120.1525870625791; Wed, 09 May 2018 05:57:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525870625; cv=none; d=google.com; s=arc-20160816; b=mfpGrFB2XBsEjoAt3kMuXtju0Y3bvBLM24Ar7Iwng99Y3l3SDtsQL6/dwQShMj2Olf MoSNb6Xtd8beE2Q4xTLP/6oFTWdiHJ5YRy/2EiqB5s5G2EALAHP5ZF+kKagsn/WFwzD6 PMQ4YeJEqgVV/WNoXUEGP04U6b2O5/R8thCHKrxw7M8Xm4O5qQtL/naBsYQ0o6qHrkJ3 bmkesFvKFUc0ABp7W8UWmwLZ6ZttzT1kJGRMcmYwGXTWIPEZ7FLy8tPUZ05ZJYkGP5J8 Lb9Z7CNxZ05EYVNmQx8TwsCGlzlcHIpScpTmq6Ara0Q702a6lP73JlHAw/BWC917TG90 iU5w== 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=QuH+CWiZQXHdXlXlOl2fuyPOi8u2Fz2eVfsXcPAg3L0=; b=IQFyT89cQZwESaR2IyNaOOkL1hM3Kh28oNCVvQZ61OwA3pQNi98gvZb+axnotTBcN3 43E39d3Y+696SsSMKEgNqt7tF8LLVO6UCsPcLXEoSkbhoyb7dO2spNRXgov7whLbiLCP 7TBwiD//MoRJTAMZYdJLeBaNah+jvEfx4SS5maFnzGBYG5quBVb86K7trs4kJ7TN41dB FZqDxyiePC97svUkM79OcNgPUdcZNq0gftW/XxsE/7Ihur9hLu5WCp3tgMWTJEp8guVa 8av9tYgnwN+OiAbEo+qZAdiGTtq/gSIJsQTB4ZfOuW8kaLF0pk0cGNf9eXlz1nGI+Mhe vgew== 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 l6-v6si13384244pgs.419.2018.05.09.05.56.50; Wed, 09 May 2018 05:57:05 -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 S934857AbeEIM4O (ORCPT + 99 others); Wed, 9 May 2018 08:56:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:56245 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934328AbeEIM4M (ORCPT ); Wed, 9 May 2018 08:56:12 -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 657F3ADE1; Wed, 9 May 2018 12:56:11 +0000 (UTC) Date: Wed, 9 May 2018 14:56:11 +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: <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 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 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