Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1653747pxb; Fri, 26 Feb 2021 17:36:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJyw6zCRMSbdmcLbDAkEsFXL7hP53u/u5vdSaT0HjXcRY0L2qYmhFolPkrfjeEFNfRtUc1jG X-Received: by 2002:a05:6402:1855:: with SMTP id v21mr6270893edy.310.1614389807876; Fri, 26 Feb 2021 17:36:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614389807; cv=none; d=google.com; s=arc-20160816; b=oBqvVJWjpJo5Syn5f4cj9r9B89wUfZ2BRFQ8qeUH6BfoiYpo1XlgQ4upgv/lwQal4S mNRjP4XgKJA67SxJT3YfauC3JAiz3vxfd2TFOtWlCCBWIvMGKYXYGMBzkEWLNAEb9xFq ruUYc2c1SkuiN6ysJBQ0vS5/oOpx0niahulzJNUshmnH0dRC32Rqr+j4lEbeQ3x2pj9K aHOI0uYfm9cne6cgCTk4Qo1aUhg3e/AK0DcLDmjxhp91stWejKv9Bin5smkU9B4sqP4o M5rDSgpJd9kyCLQbDcMa2Iwidf6cr8uPbwrd6mtnwAoAu7qkFFrGsQQczZlKbeR/cXzq NkMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=7/mS4JlhW7SeQffZJqsZzshwjd7P2X3tlrkAYmIL+wI=; b=ZS7EFMoBpXiAhdOvqAFQ79myGpta+jpFCvPprjO2LyBZKftpTBkLSIQxHeRKT0Gwwt 2sxnUXGiNWWTVulP6ooXQad4jYYEppfpZqsFrDKgmHXg6M/zmF724Yvju44XpE2DaOF5 ym63OVrro/aVlpgJWmhyO8pbVgIJYUbzhzgIAqO6PmVkZf36oobmsQLUbmFsn00RHNPo PZCYqo2i9MZMDAyHLhkRvc93rDlrdY88Q7ujkGdBYbq9KDc8PDTUqwXhJIDD7KGN/Czp AgUTj4XSPSwWOhBwKe5i79A7rkE1rDOyFL2B8z6PSTQTIB2t83wQtxPuLGBfLqJph8MQ HRqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=aC08uKlZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c11si6753716edy.117.2021.02.26.17.36.25; Fri, 26 Feb 2021 17:36:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=aC08uKlZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230008AbhB0Bcf (ORCPT + 99 others); Fri, 26 Feb 2021 20:32:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229990AbhB0Bce (ORCPT ); Fri, 26 Feb 2021 20:32:34 -0500 Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70C28C06174A for ; Fri, 26 Feb 2021 17:31:54 -0800 (PST) Received: by mail-oo1-xc32.google.com with SMTP id n19so2612988ooj.11 for ; Fri, 26 Feb 2021 17:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=7/mS4JlhW7SeQffZJqsZzshwjd7P2X3tlrkAYmIL+wI=; b=aC08uKlZHTNs2CPHxzjC/fUCCCnh0DnACmBgKfTwnQWKsP13bg/Ux/c5smAnxatYjd YVgxutv5NXfmHDvo8VUeIa8hk76n/DbEiefDaH/xHVa/2gytf4In8gdjIBp20uV+kKUM Fg3ZCBAYmsyYlVYE8b2449cYjxZbZHQG4lKPdMuhFqD8JzoVviW+TNrNMg25LViceLy3 miwJXGZ4gSAmP8W0CQUzyG8H3uj9Hbi8qynjg7IyDOagw1vt+pW8fmtrE+7R43QmrJhV UesR7zDi0FXTFI93FrfrtqdFsKqwNoL9KhSztPlxMjSOtTwJccp/Cx+YRmCJDxkQgdAs Xrhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=7/mS4JlhW7SeQffZJqsZzshwjd7P2X3tlrkAYmIL+wI=; b=VeqV+J22/LHtvUVZGyJVU3dHJ5X53KaeU4CdlnYjpS8hfCXRcmTJgyA4sepREFoTWm 6BLa/TVDUT/tUZ0BR1TTwI5O0G0c9g1jWO1V5bXAMoXJuWb2EcscO6XTD0M2fUkhXSR5 ujAp+v56MkBfiKgFBB5UgsEfQffQQhpyNIC5xYDal81GexcVkHvjiugaVOmwbiaMmfP+ alnnmlAd7FETnCRCGrYB0daonB6itpmVEDdUtl8K7fOu1srmJ/kvQNOywAT85nULn0VG ZLQBKuIm0Rg7RLqmM3VLE1ce+SoTXbtF3AMKGnzff+dJbDESLv02csEKe97AHjIUEfA4 xMLw== X-Gm-Message-State: AOAM532d9Y7aeDQj/zCfaG6NZ9tI0rou2LgnkBSevdaQkXqffmMybtlP sSgjN8v84KdxGd16isFfGNWdog== X-Received: by 2002:a4a:ab8d:: with SMTP id m13mr4484432oon.57.1614389513542; Fri, 26 Feb 2021 17:31:53 -0800 (PST) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 88sm2089884oto.3.2021.02.26.17.31.52 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Fri, 26 Feb 2021 17:31:53 -0800 (PST) Date: Fri, 26 Feb 2021 17:31:40 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Andrew Morton cc: Palmer Dabbelt , atishp@atishpatra.org, peterz@infradead.org, srikar@linux.vnet.ibm.com, valentin.schneider@arm.com, vbabka@suse.cz, mpe@ellerman.id.au, Palmer Dabbelt , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@android.com, "Kirill A. Shutemov" Subject: Re: [PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA In-Reply-To: <20210226123716.6bc2a463e0ee9d1770c7966b@linux-foundation.org> Message-ID: References: <20210226201721.510177-1-palmer@dabbelt.com> <20210226123716.6bc2a463e0ee9d1770c7966b@linux-foundation.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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_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 = 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=n? 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(). Hugh