linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux MM <linux-mm@kvack.org>,
	Daniel Jordan <daniel.m.jordan@oracle.com>,
	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 12:14:59 +0100	[thread overview]
Message-ID: <20190806111459.GH2739@techsingularity.net> (raw)
In-Reply-To: <CALOAHbAzRC9m8bw8ounK5GF2Ss-yxvzAvRw10HNj-Y78iEx2Qg@mail.gmail.com>

On Tue, Aug 06, 2019 at 05:32:54PM +0800, Yafang Shao wrote:
> On Tue, Aug 6, 2019 at 5:25 PM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > 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.
> > --
> 
> If we do it like this, then vm.min_slab_ratio will not take effect if
> there're enough relcaimable page cache.
> Seems there're bugs in the original behavior as well.
> 

Typically that would be done as a separate patch with a standalone
justification for it. The first patch should simply restore expected
behaviour with a Fixes: tag noting that the change in behaviour was
unintentional.

-- 
Mel Gorman
SUSE Labs


  reply	other threads:[~2019-08-06 11:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-06  7:19 [PATCH v2] mm/vmscan: shrink slab in node reclaim Yafang Shao
2019-08-06  7:35 ` Michal Hocko
2019-08-06  7:41   ` Michal Hocko
2019-08-06  8:57     ` Yafang Shao
2019-08-06  9:05       ` Michal Hocko
2019-08-06  9:15         ` Yafang Shao
2019-08-06  9:25           ` Michal Hocko
2019-08-06  9:32             ` Yafang Shao
2019-08-06 11:14               ` Mel Gorman [this message]
2019-08-06 11:35                 ` Yafang Shao
2019-08-06 15:59                   ` Daniel Jordan
2019-08-07  1:03                     ` Yafang Shao
2019-08-07 15:03                       ` Daniel Jordan
2019-08-06  9:50             ` Mel Gorman
2019-08-06  9:54               ` Yafang Shao
2019-08-06 10:28                 ` Michal Hocko
2019-08-06 10:59                   ` Yafang Shao
2019-08-06 11:09                     ` Michal Hocko
2019-08-06 11:34                       ` Yafang Shao
2019-08-06 11:58                     ` Michal Hocko
2019-08-06  8:23   ` Yafang Shao
2019-08-06 15:29     ` Daniel Jordan
2019-08-07  1:00       ` Yafang Shao
2019-08-07 15:03         ` Daniel Jordan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190806111459.GH2739@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=daniel.m.jordan@oracle.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=shaoyafang@didiglobal.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).