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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 98941C433DB for ; Sat, 27 Feb 2021 03:05:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0003E64EDC for ; Sat, 27 Feb 2021 03:05:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0003E64EDC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 580E48D0011; Fri, 26 Feb 2021 22:05:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5320D8D0001; Fri, 26 Feb 2021 22:05:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 422878D0011; Fri, 26 Feb 2021 22:05:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 2C48C8D0001 for ; Fri, 26 Feb 2021 22:05:46 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DD51E8249980 for ; Sat, 27 Feb 2021 03:05:45 +0000 (UTC) X-FDA: 77862557850.09.6842C6B Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf07.hostedemail.com (Postfix) with ESMTP id A3466A0009CE for ; Sat, 27 Feb 2021 03:05:44 +0000 (UTC) Received: by mail-pl1-f173.google.com with SMTP id ba1so6314481plb.1 for ; Fri, 26 Feb 2021 19:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20150623.gappssmtp.com; s=20150623; h=date:subject:in-reply-to:message-id:mime-version :content-transfer-encoding:cc:from:to; bh=CErTn4OA/0ZhE2vq/HB1zN/NVtPl48RSykIsKZFvFZQ=; b=z8KY6PvLZ5e2O8z3iDTzzfY7WlI/SjutcIjnorrbmHPIdXe5XqnJPxjg7nJcRCsNsW tGtmMpfr3Yvid44eWaBicqP8k7/ZgZ3BMMmWLsyBPn+OYkRlmxAOm8NWflTJWAEapWvH z8OKrar/3yErQxPQGu3342K3kmhrlWpok95Awh1z7WDi6n4FCC6/giCkF0HlvrUG3QPs 3N0Id0+WPrfvky+CAbEwIgHWJg59M5JqbpONJihiCvh5gHB4Xpl9m4CFjWw2E4f5IXPS uT74A/oP605z378Qt70h7SmfR2NC35CAZ3tP/z/sdmaJ/aX8lDx7n62EtLefWiKhiMvW q7Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:message-id:mime-version :content-transfer-encoding:cc:from:to; bh=CErTn4OA/0ZhE2vq/HB1zN/NVtPl48RSykIsKZFvFZQ=; b=r2TTFSM/Mc7tlUVP2CGGPSvnyiCe4o+5iDtTcJS8X6P2Kf6G1wwDJS0wGZ2+k66C2U mQMbCkWImgjRTE3Q3qd/JL0Oqx1L61UVVj/s254Tukqr6yU+pumZzbdPNnVRC6k/okiQ WmstaacC0zfEm0YBVDpudjUqN5Gg9JVBs1aV5r8dQJTR/nTK5BQzcKH/YcGaNRvCm+JM hvHLAad8SjljuHdSyqChrw6TrA8HKjPi7vY/Z9wYTHeR2hJlBvmWVHlxEARkaBRkyHzR gxP237iVdBFmhe19wHCOwJceniQT2+4PWuls9YCT8eeeEOEjs+BUC9dxl/bjsQfkgPwO Q/6Q== X-Gm-Message-State: AOAM533YdoaEuEfdPfluZD92KKhKpDboJReHTX81iNzW1jWVVdNY0zoI aLch9Cw87JLs60W9A01hj+pNew== X-Google-Smtp-Source: ABdhPJyBnXuV/s+DrX/Or6kRPo7C8q8gGVT+esbNFeOphxZLYo2TOJem6uMnQ7L4s/oV5oDtdDibTQ== X-Received: by 2002:a17:90a:e2cb:: with SMTP id fr11mr6489864pjb.2.1614395143997; Fri, 26 Feb 2021 19:05:43 -0800 (PST) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id e129sm11103372pfh.87.2021.02.26.19.05.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Feb 2021 19:05:43 -0800 (PST) Date: Fri, 26 Feb 2021 19:05:43 -0800 (PST) X-Google-Original-Date: Fri, 26 Feb 2021 19:05:09 PST (-0800) Subject: Re: [PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA In-Reply-To: Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed CC: akpm@linux-foundation.org, atishp@atishpatra.org, peterz@infradead.org, srikar@linux.vnet.ibm.com, valentin.schneider@arm.com, vbabka@suse.cz, mpe@ellerman.id.au, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@android.com, kirill.shutemov@linux.intel.com From: Palmer Dabbelt To: hughd@google.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A3466A0009CE X-Stat-Signature: beq134qrqujnso81fr8twro6e96r9x93 Received-SPF: none (dabbelt.com>: No applicable sender policy available) receiver=imf07; identity=mailfrom; envelope-from=""; helo=mail-pl1-f173.google.com; client-ip=209.85.214.173 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614395144-758952 Content-Transfer-Encoding: quoted-printable 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 Fri, 26 Feb 2021 17:31:40 PST (-0800), hughd@google.com wrote: > On Fri, 26 Feb 2021, Andrew Morton wrote: >> On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt = wrote: >> > From: Palmer Dabbelt >> > >> > This is only useful under CONFIG_NUMA. IIUC skipping the check is t= he >> > right thing to do here, as without CONFIG_NUMA there will never be a= ny >> > large node distances on non-NUMA systems. >> > >> > I expected this to manifest as a link failure under (!CONFIG_NUMA && >> > CONFIG_TRANSPARENT_HUGE_PAGES), but I'm not actually seeing that. I >> > think the reference is just getting pruned before it's checked, but = I >> > didn't get that from reading the code so I'm worried I'm missing >> > something. >> > >> > Either way, this is necessary to guard the definition of >> > node_reclaim_distance with CONFIG_NUMA. >> > >> > Signed-off-by: Palmer Dabbelt >> > --- >> > mm/khugepaged.c | 2 ++ >> > 1 file changed, 2 insertions(+) >> > >> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c >> > index a7d6cb912b05..b1bf191c3a54 100644 >> > --- a/mm/khugepaged.c >> > +++ b/mm/khugepaged.c >> > @@ -819,8 +819,10 @@ static bool khugepaged_scan_abort(int nid) >> > for (i =3D 0; i < MAX_NUMNODES; i++) { >> > if (!khugepaged_node_load[i]) >> > continue; >> > +#ifdef CONFIG_NUMA >> > if (node_distance(nid, i) > node_reclaim_distance) >> > return true; >> > +#endif >> > } >> > return false; >> > } >> >> This makes the entire loop a no-op. Perhaps Kirill can help take a >> look at removing unnecessary code in khugepaged.c when CONFIG_NUMA=3Dn= ? > > First lines of khugepaged_scan_abort() say > if (!node_reclaim_mode) > return false; > > And include/linux/swap.h says > #ifdef CONFIG_NUMA > extern int node_reclaim_mode; > extern int sysctl_min_unmapped_ratio; > extern int sysctl_min_slab_ratio; > #else > #define node_reclaim_mode 0 > #endif > > So, no need for an #ifdef CONFIG_NUMA inside khugepaged_scan_abort(). Ah, thanks, I hadn't seen that. That certainly explains the lack of an=20 undefined reference. That said: do we generally rely on DCE to prune references to undefined=20 symbols? This particular one seems like it'd get reliably deleted, but i= t=20 seems like a fragile thing to do in general. This kind of stuff would=20 certainly make some code easier to write, though. I don't really care all that much, though, as I was just sending this alo= ng due=20 to some build failure report from a user that I couldn't reproduce. It l= ooked=20 like they had some out-of-tree stuff, so in this case I'm fine on fixing = this=20 being their problem.