From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3ED99C10DCE for ; Wed, 18 Mar 2020 11:14:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EEA762076C for ; Wed, 18 Mar 2020 11:14:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EEA762076C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9D2786B0008; Wed, 18 Mar 2020 07:14:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A9496B000D; Wed, 18 Mar 2020 07:14:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E7AC6B0010; Wed, 18 Mar 2020 07:14:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by kanga.kvack.org (Postfix) with ESMTP id 75E9B6B0008 for ; Wed, 18 Mar 2020 07:14:46 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3882D2C6D for ; Wed, 18 Mar 2020 11:14:46 +0000 (UTC) X-FDA: 76608225372.22.owner37_c7e03740d95f X-HE-Tag: owner37_c7e03740d95f X-Filterd-Recvd-Size: 3871 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Wed, 18 Mar 2020 11:14:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AEDFCB243; Wed, 18 Mar 2020 11:14:41 +0000 (UTC) Date: Wed, 18 Mar 2020 12:14:39 +0100 From: Michal Hocko To: Srikar Dronamraju Cc: Andrew Morton , linux-mm@kvack.org, Mel Gorman , Michael Ellerman , Sachin Sant , Christopher Lameter , linuxppc-dev@lists.ozlabs.org, Joonsoo Kim , Kirill Tkhai , Vlastimil Babka , Bharata B Rao , Nathan Lynch Subject: Re: [PATCH v2 1/4] mm: Check for node_online in node_present_pages Message-ID: <20200318111439.GJ21362@dhcp22.suse.cz> References: <20200318072810.9735-1-srikar@linux.vnet.ibm.com> <20200318072810.9735-2-srikar@linux.vnet.ibm.com> <20200318100256.GH21362@dhcp22.suse.cz> <20200318110215.GC27520@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200318110215.GC27520@linux.vnet.ibm.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 18-03-20 16:32:15, Srikar Dronamraju wrote: > * Michal Hocko [2020-03-18 11:02:56]: > > > On Wed 18-03-20 12:58:07, Srikar Dronamraju wrote: [...] > > > -#define node_present_pages(nid) (NODE_DATA(nid)->node_present_pages) > > > -#define node_spanned_pages(nid) (NODE_DATA(nid)->node_spanned_pages) > > > +#define node_present_pages(nid) \ > > > + (node_online(nid) ? NODE_DATA(nid)->node_present_pages : 0) > > > +#define node_spanned_pages(nid) \ > > > + (node_online(nid) ? NODE_DATA(nid)->node_spanned_pages : 0) > > > > I believe this is a wrong approach. We really do not want to special > > case all the places which require NODE_DATA. Can we please go and > > allocate pgdat for all possible nodes? > > > > I can do that but the question I had was should we make this change just for > Powerpc or should the change be for other archs. No, we shouldn't, really. If NODE_DATA is non-null for all possible nodes then this shouldn't be really necessary and arch specific. > NODE_DATA initialization always seems to be in arch specific code. > > The other archs that are affected seem to be mips, sh and sparc > These archs seem to have making an assumption that NODE_DATA has to be local > only, Which is all good and fine for nodes that hold some memory. If those architectures support memory less nodes at all then I do not see any problem to have remote pgdata. > For example on sparc / arch/sparc/mm/init_64.c in allocate_node_data function. > > NODE_DATA(nid) = memblock_alloc_node(sizeof(struct pglist_data), > SMP_CACHE_BYTES, nid); > if (!NODE_DATA(nid)) { > prom_printf("Cannot allocate pglist_data for nid[%d]\n", nid); > prom_halt(); > } > > NODE_DATA(nid)->node_id = nid; This code is not about memroy less nodes, is it? It looks more like a allocation failure panic-like handling because there is not enough memory to hold pgdat. This also strongly suggests that this platform doesn't really expect memory less nodes in the early init path. > So even if I make changes to allocate NODE_DATA from fallback node, I may not > be able to test them. Please try to focus on the architecture you can test for. From the existing reports I have seen this looks mostly to be a problem for x86 and ppc -- Michal Hocko SUSE Labs