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 F168FC433DB for ; Sat, 27 Feb 2021 04:14:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4220F64F1F for ; Sat, 27 Feb 2021 04:14:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4220F64F1F 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 877C38D0015; Fri, 26 Feb 2021 23:14:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 829A38D0001; Fri, 26 Feb 2021 23:14:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 718CF8D0015; Fri, 26 Feb 2021 23:14:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0045.hostedemail.com [216.40.44.45]) by kanga.kvack.org (Postfix) with ESMTP id 5B82C8D0001 for ; Fri, 26 Feb 2021 23:14:50 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1B50F8249980 for ; Sat, 27 Feb 2021 04:14:50 +0000 (UTC) X-FDA: 77862731940.26.42914F5 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf29.hostedemail.com (Postfix) with ESMTP id 7DD02130 for ; Sat, 27 Feb 2021 04:14:49 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id p21so7439664pgl.12 for ; Fri, 26 Feb 2021 20:14:49 -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:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=HAWqJh5bH0SBnTvxI36sdd7e6koG3nqFv5InO++pzdY=; b=xve7mwNKx/vYEK9kReHFU6UyxBQOISTwlspvgLp0jv/P/32Kf7hFq9gUPaG9xa+A/w 9ZEx9OOTv6zBRKyJ7LtXlcLxvgLux3qIzvIphJ4ByyKHyvX3uEwBQ174q8dBT2w8Se/y uyxEpUUDPJkfNO/JLBjS9iqT9jwSCEsCPrnwdZ/UjDRluSdyj1FIfei/xbSSV0dGNZoh hKoMerrPp0K5eZGpivKf4dN8+XSYzpdrOcj3lW4EHAiD7f2m3ZPG50c89UAURhXKvkDB LejmDB9lsqlfoLIjqYOuFkAuungCwwkNYKcKcP5fg0u8AyLc6BdNnm6CpvfSMyPRoC7/ AxvQ== 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:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=HAWqJh5bH0SBnTvxI36sdd7e6koG3nqFv5InO++pzdY=; b=AOI2lPtoDiw/dEZJcp8kzRYpbj3rjaCRMBeTBC9hUNzLTwr6x1ygzBi7/W/BZc11rl 62BOZSf//EtWziXEv0e5yADGgczSYchSwCSsMNB6t86NX9BzdSj0j4bBfedj4SglCeSW JNUwyQk+I6/PXmWvG+ss6d741mlUwi1oyQEuw+I/t3SMHWJAXgztq8Hqpakw7vTF2A7o 4ngN75Ye+QO7e9RHO4PwJsBCC5G1bQN3sntO+dtWGAQFgugvAVlP/5FS/AW3CukKlbCG bJc+BD2RQarOXWvyWR9wqz3XZH1lwGLCfhleQ7EnpkyKvSgH/i7j54SEmPHbjvLy54ql 7Tkw== X-Gm-Message-State: AOAM532iKk2XT65/E4bRV8oDwdLq3YiXCOQg8UYKS9zZRjeFgJ6vpvRy sXF5XJ8wLN/ZQUek1Er29ccYfA== X-Google-Smtp-Source: ABdhPJwnZHCvJ5CYxZZAoue5BWmBrNhTCBhcDNKZasUQtgpWSzXSHo89jKW2v0Xwu7h2k9YiFZTQYA== X-Received: by 2002:a63:1505:: with SMTP id v5mr5782922pgl.95.1614399288412; Fri, 26 Feb 2021 20:14:48 -0800 (PST) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id j1sm10773163pfr.78.2021.02.26.20.14.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Feb 2021 20:14:47 -0800 (PST) Date: Fri, 26 Feb 2021 20:14:47 -0800 (PST) X-Google-Original-Date: Fri, 26 Feb 2021 20:14:32 PST (-0800) Subject: Re: [PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA In-Reply-To: CC: hughd@google.com, 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 Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed X-Stat-Signature: t7w1rexwnbzko3jdnzdqd6htqj1ut9ko X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 7DD02130 Received-SPF: none (dabbelt.com>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=mail-pg1-f180.google.com; client-ip=209.85.215.180 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614399289-759688 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 19:41:40 PST (-0800), hughd@google.com wrote: > On Fri, 26 Feb 2021, Palmer Dabbelt wrote: >> 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 the >> > > > right thing to do here, as without CONFIG_NUMA there will never = be any >> > > > large node distances on non-NUMA systems. >> > > > >> > > > I expected this to manifest as a link failure under (!CONFIG_NUM= A && >> > > > 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 a= n >> undefined reference. >> >> That said: do we generally rely on DCE to prune references to undefine= d >> symbols? This particular one seems like it'd get reliably deleted, bu= t it >> seems like a fragile thing to do in general. This kind of stuff would >> certainly make some code easier to write, though. > > Yes, the kernel build very much depends on the optimizer eliminating > dead code, in many many places. We do prefer to keep the #ifdefs to > the header files as much as possible. OK, makes sense. Thanks! >> I don't really care all that much, though, as I was just sending this = along >> due to some build failure report from a user that I couldn't reproduce= . It >> looked like they had some out-of-tree stuff, so in this case I'm fine = on >> fixing this being their problem. > > I didn't see your 2/2 at the time; but wouldn't be surprised if that > needs 1/2, to avoid an error on undeclared node_reclaim_distance before > the optimizer comes into play. If so, best just to drop 2/2 too. Ya, definitely. Sorry for the noise!