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 2EE68C433F5 for ; Tue, 12 Apr 2022 01:36:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C8086B0071; Mon, 11 Apr 2022 21:36:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74FA66B0073; Mon, 11 Apr 2022 21:36:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F0986B0074; Mon, 11 Apr 2022 21:36:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id 4A4F16B0071 for ; Mon, 11 Apr 2022 21:36:40 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DDC6D8249980 for ; Tue, 12 Apr 2022 01:36:39 +0000 (UTC) X-FDA: 79346512518.22.EB2109A Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf10.hostedemail.com (Postfix) with ESMTP id AD86DC0003 for ; Tue, 12 Apr 2022 01:36:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649727398; x=1681263398; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=pQGXf75WjtOKpwGRrA2vxPYLcX3Vjo5dFDxMSXaxBfk=; b=gE9WbhrcBLWnSPQF23cG54vjUp2SmanwSYipm5gj5vSlB2bkSHAgmnJS zJcUwzwOhPiEg7YVo5ZQPCAmIJzmpCXK/lBaNK669V/48V2x1jExQyEcu wt0HPn5kcdbtR07z6k9Y8Fu5q2lThATpMWMmuCzWiNBsAC6c3RviU1deh ui4vI9h3IT4SSrbrV8HTNT9wdgM/8/NNj/BoO2tmGBtuUU9LCOI55lKDo TQVxLnyEwr+UgKbQozsGrL8hGzuHIpXsL0x+9iYlkC9UOuMfxnWMWNbtr rs4yNnntuMh3CzCFWAyFi+iWYGRTQX1cLfFdHHansUbLW2pDB3CGRsmko g==; X-IronPort-AV: E=McAfee;i="6400,9594,10314"; a="244137574" X-IronPort-AV: E=Sophos;i="5.90,252,1643702400"; d="scan'208";a="244137574" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2022 18:36:37 -0700 X-IronPort-AV: E=Sophos;i="5.90,252,1643702400"; d="scan'208";a="572503695" Received: from joliu-mobl2.ccr.corp.intel.com ([10.254.214.243]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Apr 2022 18:36:34 -0700 Message-ID: Subject: Re: [PATCH v2 7/9] mm/vmscan: take min_slab_pages into account when try to call shrink_node From: "ying.huang@intel.com" To: Miaohe Lin , akpm@linux-foundation.org, Christoph Hellwig Cc: songmuchun@bytedance.com, hch@infradead.org, willy@infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner Date: Tue, 12 Apr 2022 09:36:31 +0800 In-Reply-To: <20220409093500.10329-8-linmiaohe@huawei.com> References: <20220409093500.10329-1-linmiaohe@huawei.com> <20220409093500.10329-8-linmiaohe@huawei.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: AD86DC0003 X-Stat-Signature: 4m3m1sswsc1954rsdfb54z3np3r8tssu Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=gE9Wbhrc; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf10.hostedemail.com: domain of ying.huang@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-HE-Tag: 1649727398-820959 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 Sat, 2022-04-09 at 17:34 +0800, Miaohe Lin wrote: > Since commit 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from > shrink_zone()"), slab reclaim and lru page reclaim are done together > in the shrink_node. So we should take min_slab_pages into account > when try to call shrink_node. >=20 Looks reasonable to me, copying Johannes. Hi, Christoph, Should we check min_unmapped_pages and min_slab_pages in shrink_node() to avoid reclaim LRU when necessary and vice versa? This may be done via another 2 scan_control flags. Best Regards, Huang, Ying > Signed-off-by: Miaohe Lin > --- > =C2=A0mm/vmscan.c | 3 ++- > =C2=A01 file changed, 2 insertions(+), 1 deletion(-) >=20 > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 53f1d0755b34..ba83d8f3e53e 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -4714,7 +4714,8 @@ static int __node_reclaim(struct pglist_data *pgd= at, gfp_t gfp_mask, unsigned in > =C2=A0 noreclaim_flag =3D memalloc_noreclaim_save(); > =C2=A0 set_task_reclaim_state(p, &sc.reclaim_state); > =C2=A0 >=20 >=20 >=20 > - if (node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages) { > + if (node_pagecache_reclaimable(pgdat) > pgdat->min_unmapped_pages || > + node_page_state_pages(pgdat, NR_SLAB_RECLAIMABLE_B) > pgdat->min_= slab_pages) { > =C2=A0 /* > =C2=A0 * Free memory by calling shrink node with increasing > =C2=A0 * priorities until we have enough memory freed.