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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 28EA1C18E5B for ; Tue, 17 Mar 2020 15:29:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E8FC820714 for ; Tue, 17 Mar 2020 15:29:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E8FC820714 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 81A486B0006; Tue, 17 Mar 2020 11:29:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CA816B0007; Tue, 17 Mar 2020 11:29:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 707C56B0008; Tue, 17 Mar 2020 11:29:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id 59BCC6B0006 for ; Tue, 17 Mar 2020 11:29:29 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 525DC180AD838 for ; Tue, 17 Mar 2020 15:29:29 +0000 (UTC) X-FDA: 76605238458.22.road03_8cffe5053b142 X-HE-Tag: road03_8cffe5053b142 X-Filterd-Recvd-Size: 4082 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Tue, 17 Mar 2020 15:29:28 +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 B6359AE2D; Tue, 17 Mar 2020 15:29:22 +0000 (UTC) Subject: Re: [PATCH 2/4] mm/slub: Use mem_node to allocate a new slab To: Srikar Dronamraju Cc: Andrew Morton , linux-mm@kvack.org, Mel Gorman , Michael Ellerman , Sachin Sant , Michal Hocko , Christopher Lameter , linuxppc-dev@lists.ozlabs.org, Joonsoo Kim , Kirill Tkhai , Bharata B Rao References: <3381CD91-AB3D-4773-BA04-E7A072A63968@linux.vnet.ibm.com> <20200317131753.4074-1-srikar@linux.vnet.ibm.com> <20200317131753.4074-3-srikar@linux.vnet.ibm.com> <20200317134523.GB4334@linux.vnet.ibm.com> <3d9629d4-4a6d-d2b5-28b7-58af497671c7@suse.cz> <20200317145105.GA27520@linux.vnet.ibm.com> From: Vlastimil Babka Message-ID: Date: Tue, 17 Mar 2020 16:29:21 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200317145105.GA27520@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 3/17/20 3:51 PM, Srikar Dronamraju wrote: > * Vlastimil Babka [2020-03-17 14:53:26]: > >> >> > >> >> > Mitigate this by allocating the new slab from the node_numa_mem. >> >> >> >> Are you sure this is really needed and the other 3 patches are not enough for >> >> the current SLUB code to work as needed? It seems you are changing the semantics >> >> here... >> >> >> > >> > The other 3 patches are not enough because we don't carry the searchnode >> > when the actual alloc_pages_node gets called. >> > >> > With only the 3 patches, we see the above Panic, its signature is slightly >> > different from what Sachin first reported and which I have carried in 1st >> > patch. >> >> Ah, I see. So that's the missing pgdat after your series [1] right? > > Yes the pgdat would be missing after my cpuless, memoryless node patchset. > However.. >> >> That sounds like an argument for Michal's suggestions that pgdats exist and have >> correctly populated zonelists for all possible nodes. > > Only the first patch in this series would be affected by pgdat existing or > not. Even if the pgdat existed, the NODE_DATA[nid]->node_present_pages > would be 0. Right? So it would look at node_to_mem_node(). And since node 0 is > cpuless it would return 0. I thought the point was to return 1 for node 0. > If we pass this node 0 (which is memoryless/cpuless) to > alloc_pages_node. Please note I am only setting node_numa_mem only > for offline nodes. However we could change this to set for all offline and > memoryless nodes. That would indeed make sense. But I guess that alloc_pages would still crash as the result of numa_to_mem_node() is not passed down to alloc_pages() without this patch. In __alloc_pages_node() we currently have "The node must be valid and online" so offline nodes don't have zonelists. Either they get them, or we indeed need something like this patch. But in order to not make get_any_partial() dead code, the final replacement of invalid node with a valid one should be done in alloc_slab_page() I guess? >> node_to_mem_node() could be just a shortcut for the first zone's node in the >> zonelist, so that fallback follows the topology. >> >> [1] >> https://lore.kernel.org/linuxppc-dev/20200311110237.5731-1-srikar@linux.vnet.ibm.com/t/#m76e5b4c4084380b1d4b193d5aa0359b987f2290e >> > > >