Re: [PATCH v2] mm/vmscan: shrink slab in node reclaim

From: Michal Hocko <mhocko@kernel.org>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Linux MM <linux-mm@kvack.org>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Christoph Lameter <cl@linux.com>,
	Yafang Shao <shaoyafang@didiglobal.com>
Subject: Re: [PATCH v2] mm/vmscan: shrink slab in node reclaim
Date: Tue, 6 Aug 2019 11:25:31 +0200	[thread overview]
Message-ID: <20190806092531.GN11812@dhcp22.suse.cz> (raw)
In-Reply-To: <CALOAHbDO5qmqKt8YmCkTPhh+m34RA+ahgYVgiLx1RSOJ-gM4Dw@mail.gmail.com>

On Tue 06-08-19 17:15:05, Yafang Shao wrote:
> On Tue, Aug 6, 2019 at 5:05 PM Michal Hocko <mhocko@kernel.org> wrote:
[...]
> > > As you said, the direct reclaim path set it to 1, but the
> > > __node_reclaim() forgot to process may_shrink_slab.
> >
> > OK, I am blind obviously. Sorry about that. Anyway, why cannot we simply
> > get back to the original behavior by setting may_shrink_slab in that
> > path as well?
> 
> You mean do it as the commit 0ff38490c836 did  before ?
> I haven't check in which commit the shrink_slab() is removed from

What I've had in mind was essentially this:

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 7889f583ced9..8011288a80e2 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4088,6 +4093,7 @@ static int __node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, unsigned in
 		.may_unmap = !!(node_reclaim_mode & RECLAIM_UNMAP),
 		.may_swap = 1,
 		.reclaim_idx = gfp_zone(gfp_mask),
+		.may_shrinkslab = 1;
 	};
 
 	trace_mm_vmscan_node_reclaim_begin(pgdat->node_id, order,

shrink_node path already does shrink slab when the flag allows that. In
other words get us back to before 1c30844d2dfe because that has clearly
changed the long term node reclaim behavior just recently.
-- 
Michal Hocko
SUSE Labs

