On Tue 06-08-19 17:15:05, Yafang Shao wrote: > On Tue, Aug 6, 2019 at 5:05 PM Michal Hocko <mhocko@xxxxxxxxxx> 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
