Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1509966pxb; Fri, 26 Feb 2021 12:39:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJy0VNjBaHF05X+/3jRlY+TTiiWASrkJ/gkN3aBjb4ZYTgYri3406cDG/XrQ0fQaCHjMwSbB X-Received: by 2002:a05:6402:3514:: with SMTP id b20mr5357368edd.100.1614371991477; Fri, 26 Feb 2021 12:39:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614371991; cv=none; d=google.com; s=arc-20160816; b=bZM5uAlvG27mNrkx+7/x80cLUf/Flji5zNmLYan6SsdsyyE7uKOVqUpkWgyC/brSEJ TQO6T4mpVBoweM8qnkg8xZ6Eke47NThiv6sEjqqZGNOPlvumDpYediXCSZ4tDUj3qFUA X1jFhMmaHottI/QklTrhxNdO84vb19ASNcQGIfNuUWPWUgsc6+QV3Dc8+9UGdcxRv2jq /TyfIM1DaBywV12tDsAu8p9r9rJgNGJi14RQYov4znsk6C8L+I6A3ixfOCUWHKQTHJ27 6AWXwwSaC+hEVD2x8eTuamilLHII7FwL7u67q8sFIdzsXjlEfl1zHvMZdNVkie6zF35b STvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=d2rvUjn5cg2/9uJWJsI4qlZyw/BkT5Hpf21iLZ4wgQE=; b=yaNkrYC0SpXG2FIyklLeXBO7ka9Yr6g6gnXNDjCMhCpeXFSUP0nFjE3+4HJXCnXH+M wfhXdU3H3SgkieNPM8J/3ni9H6cTc/wGU+3lnBU/kbPWsGFqdmRZSWWts2Si+x9HxOid IyW2z2T8SWzdV1PmMA5dvGN/z8e1MbC6E29tpHgkUDUrb9mM9rxi0F8Ma6YQlBXn2ujr eosVdO8QgV4JBpyKMioFCVB6kWVfTieNAFTFRSMwquI9JKj6D4OuEY6ETsS2qFcogYoS GSF9MnOBzkbJwPTgc5TcRADwi8harWZKLYvcFJCYSrx0MhB+R+o+OgIZbCvBYyd1uyz2 SGeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=zJhisgXn; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m15si6184231edd.260.2021.02.26.12.39.26; Fri, 26 Feb 2021 12:39:51 -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=@linux-foundation.org header.s=korg header.b=zJhisgXn; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230305AbhBZUiB (ORCPT + 99 others); Fri, 26 Feb 2021 15:38:01 -0500 Received: from mail.kernel.org ([198.145.29.99]:50764 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230477AbhBZUh6 (ORCPT ); Fri, 26 Feb 2021 15:37:58 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5521E64F03; Fri, 26 Feb 2021 20:37:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1614371837; bh=Ly0f27B7LvWPQIY/noxzHUfAiBR7+fZJjZHCqygyerw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=zJhisgXnLiT9g94dR6TY00koT/Ql+rflRrpcB41mBSqMhYtj/D6Yx166tD0LQTGmp qlINLn7lfkO6b+9EncYHBQ+FTqGI6/MOMpYyC76WwLDirIBX32wST/4Dz+JkrSKAHo WmM/b4uUHPf7DrEkKbDAoqnnT6lrzQZEjJ7aCOPI= Date: Fri, 26 Feb 2021 12:37:16 -0800 From: Andrew Morton To: Palmer Dabbelt Cc: 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 Message-Id: <20210226123716.6bc2a463e0ee9d1770c7966b@linux-foundation.org> In-Reply-To: <20210226201721.510177-1-palmer@dabbelt.com> References: <20210226201721.510177-1-palmer@dabbelt.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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?