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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 156A2C433F5 for ; Wed, 1 Jun 2022 06:12:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 467C36B0071; Wed, 1 Jun 2022 02:12:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 419676B0073; Wed, 1 Jun 2022 02:12:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DBBC6B0074; Wed, 1 Jun 2022 02:12:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1FB206B0071 for ; Wed, 1 Jun 2022 02:12:34 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 9E583120643 for ; Wed, 1 Jun 2022 06:12:33 +0000 (UTC) X-FDA: 79528647786.19.C2E5B84 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf10.hostedemail.com (Postfix) with ESMTP id 5402DC0052 for ; Wed, 1 Jun 2022 06:11:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654063951; x=1685599951; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=ejk+xQ9b0k0wC9j8WfBHQoNfMzyyS5YZ0KCtVf4OBQw=; b=dyMBUo5lJSELZTkGKFqw+ebNrMhfcEEToI6Jzmc+hwpYZigZBAzq5M70 yvY6eDhKSg3Fr29J8eajZyeYKbXSQlvBzlRZ6HGfDdq5Ogowkh0vaZkHa FjsmPwTmVofAbBxCWH9NBUlhqo0PxkGJ2Bo6B1wPylqJj9nX2JzbmRbLw B3UpPc1zN8trc1378VlpC8xBi8ziifX9EghpH3wUHCkJEPD+CTtClGIRF o7KqCXsDHWudbJrXtIKmFCXg3BKF6Q+qPMZc02INTBROPP6e2mx0rh19c pkBV+80FHoN46tK+A9OFrZiR4igUYICMT976fCzHcRAJhhR2RP/fK1pFo A==; X-IronPort-AV: E=McAfee;i="6400,9594,10364"; a="275495725" X-IronPort-AV: E=Sophos;i="5.91,266,1647327600"; d="scan'208";a="275495725" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2022 23:12:29 -0700 X-IronPort-AV: E=Sophos;i="5.91,266,1647327600"; d="scan'208";a="606087592" Received: from liangqiz-mobl.ccr.corp.intel.com ([10.254.214.157]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 May 2022 23:12:25 -0700 Message-ID: <61c47f98b4c0be1d5da5e097779412f9edd70753.camel@intel.com> Subject: Re: [PATCH 2/6] mm/vmscan: use node_is_toptier helper in node_reclaim From: Ying Huang To: "Aneesh Kumar K.V" , Davidlohr Bueso , linux-mm@kvack.org, Wei Xu Cc: mhocko@kernel.org, akpm@linux-foundation.org, rientjes@google.com, yosryahmed@google.com, hannes@cmpxchg.org, shakeelb@google.com, dave.hansen@linux.intel.com, tim.c.chen@linux.intel.com, roman.gushchin@linux.dev, gthelen@google.com, a.manzanares@samsung.com, heekwon.p@samsung.com, gim.jongmin@samsung.com, linux-kernel@vger.kernel.org Date: Wed, 01 Jun 2022 14:12:22 +0800 In-Reply-To: <87h755dip9.fsf@linux.ibm.com> References: <20220416053902.68517-1-dave@stgolabs.net> <20220416053902.68517-3-dave@stgolabs.net> <87h755dip9.fsf@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: ejb8knfx7rbauyisqz7czs4pw145u3pn X-Rspam-User: Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dyMBUo5l; spf=none (imf10.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.65) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5402DC0052 X-HE-Tag: 1654063907-203620 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 Tue, 2022-05-31 at 17:20 +0530, Aneesh Kumar K.V wrote: > Davidlohr Bueso writes: > > > We have helpers for a reason. > > > > Signed-off-by: Davidlohr Bueso > > --- > >  mm/vmscan.c | 2 +- > >  1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > index 1678802e03e7..cb583fcbf5bf 100644 > > --- a/mm/vmscan.c > > +++ b/mm/vmscan.c > > @@ -4750,7 +4750,7 @@ int node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned int order) > >   * over remote processors and spread off node memory allocations > >   * as wide as possible. > >   */ > > - if (node_state(pgdat->node_id, N_CPU) && pgdat->node_id != numa_node_id()) > > + if (node_is_toptier(pgdat->node_id) && pgdat->node_id != numa_node_id()) > >   return NODE_RECLAIM_NOSCAN; > >   > > > >   if (test_and_set_bit(PGDAT_RECLAIM_LOCKED, &pgdat->flags)) > > > Are we really looking at the top tier in a tiered memory hierarchy here? > The comment seems to suggest we are looking at local NUMA node? The code change itself is correct. But it is an implementation details that node_is_toptier() == node_state(, N_CPU). And after we supporting more memory tiers (like GPU, HBM), we will change the implementation of node_is_toptier() soon. So I think that it's better to keep the original code. Best Regards, Huang, Ying