linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>, Michal Hocko <mhocko@suse.cz>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 2/4] mm: vmscan: rework compaction-ready signaling in direct reclaim
Date: Mon, 23 Jun 2014 13:20:56 -0400	[thread overview]
Message-ID: <20140623172056.GN7331@cmpxchg.org> (raw)
In-Reply-To: <20140623130705.GM10819@suse.de>

Hi Mel,

On Mon, Jun 23, 2014 at 02:07:05PM +0100, Mel Gorman wrote:
> On Fri, Jun 20, 2014 at 12:33:48PM -0400, Johannes Weiner wrote:
> > Page reclaim for a higher-order page runs until compaction is ready,
> > then aborts and signals this situation through the return value of
> > shrink_zones().  This is an oddly specific signal to encode in the
> > return value of shrink_zones(), though, and can be quite confusing.
> > 
> > Introduce sc->compaction_ready and signal the compactability of the
> > zones out-of-band to free up the return value of shrink_zones() for
> > actual zone reclaimability.
> > 
> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
> > ---
> >  mm/vmscan.c | 67 ++++++++++++++++++++++++++++---------------------------------
> >  1 file changed, 31 insertions(+), 36 deletions(-)
> > 
> > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > index 19b5b8016209..ed1efb84c542 100644
> > --- a/mm/vmscan.c
> > +++ b/mm/vmscan.c
> > @@ -65,6 +65,9 @@ struct scan_control {
> >  	/* Number of pages freed so far during a call to shrink_zones() */
> >  	unsigned long nr_reclaimed;
> >  
> > +	/* One of the zones is ready for compaction */
> > +	int compaction_ready;
> > +
> >  	/* How many pages shrink_list() should reclaim */
> >  	unsigned long nr_to_reclaim;
> >  
> 
> You are not the criminal here but scan_control is larger than it needs
> to be and the stack usage of reclaim has reared its head again.
> 
> Add a preparation patch that convert sc->may* and sc->hibernation_mode
> to bool and moves them towards the end of the struct. Then add
> compaction_ready as a bool.

Good idea, I'll do that.

> > @@ -2292,15 +2295,11 @@ static void shrink_zone(struct zone *zone, struct scan_control *sc)
> >  }
> >  
> >  /* Returns true if compaction should go ahead for a high-order request */
> > -static inline bool compaction_ready(struct zone *zone, struct scan_control *sc)
> > +static inline bool compaction_ready(struct zone *zone, int order)
> > 
> >  {
> 
> Why did you remove the use of sc->order? In this patch there is only one
> called of compaction_ready and it looks like
> 
>                      if (IS_ENABLED(CONFIG_COMPACTION) &&
>                          sc->order > PAGE_ALLOC_COSTLY_ORDER &&
>                          zonelist_zone_idx(z) <= requested_highidx &&
>                          compaction_ready(zone, sc->order)) {
> 
> So it's unclear why you changed the signature.

Everything else in compaction_ready() is about internal compaction
requirements, like checking for free pages and deferred compaction,
whereas this order check is more of a reclaim policy rule according to
the comment in the caller:

			 ...
			 * Even though compaction is invoked for any
			 * non-zero order, only frequent costly order
			 * reclamation is disruptive enough to become a
			 * noticeable problem, like transparent huge
			 * page allocations.
			 */

But it's an unrelated in-the-area-anyway change, I can split it out -
or drop it entirely - if you prefer.

> > @@ -2500,12 +2492,15 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
> >  		vmpressure_prio(sc->gfp_mask, sc->target_mem_cgroup,
> >  				sc->priority);
> >  		sc->nr_scanned = 0;
> > -		aborted_reclaim = shrink_zones(zonelist, sc);
> > +		shrink_zones(zonelist, sc);
> >  
> >  		total_scanned += sc->nr_scanned;
> >  		if (sc->nr_reclaimed >= sc->nr_to_reclaim)
> >  			goto out;
> >  
> > +		if (sc->compaction_ready)
> > +			goto out;
> > +
> 
> break?
> 
> Convert the other one to break as well. out label seems unnecessary in
> this context.

Makes sense, I'll include this in v2.

Thanks!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2014-06-23 17:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-20 16:33 [patch 1/4] mm: vmscan: remove remains of kswapd-managed zone->all_unreclaimable Johannes Weiner
2014-06-20 16:33 ` [patch 2/4] mm: vmscan: rework compaction-ready signaling in direct reclaim Johannes Weiner
2014-06-20 16:56   ` Vlastimil Babka
2014-06-20 20:24     ` Johannes Weiner
2014-06-23  7:28       ` Michal Hocko
2014-06-23  6:36   ` Minchan Kim
2014-06-23 18:20     ` Johannes Weiner
2014-06-23 13:07   ` Mel Gorman
2014-06-23 17:20     ` Johannes Weiner [this message]
2014-06-25  9:55       ` Mel Gorman
2014-06-20 16:33 ` [patch 3/4] mm: vmscan: remove all_unreclaimable() Johannes Weiner
2014-06-23  6:48   ` Minchan Kim
2014-06-23  8:35   ` Michal Hocko
2014-06-23 13:32   ` Mel Gorman
2014-06-20 16:33 ` [patch 4/4] mm: vmscan: move swappiness out of scan_control Johannes Weiner
2014-06-23  6:51   ` Minchan Kim
2014-06-23  9:12   ` Michal Hocko
2014-06-23  6:16 ` [patch 1/4] mm: vmscan: remove remains of kswapd-managed zone->all_unreclaimable Minchan Kim
2014-06-23 16:01   ` Motohiro Kosaki
2014-06-23  7:49 ` Michal Hocko
2014-06-23 12:56 ` Mel Gorman

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=20140623172056.GN7331@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=riel@redhat.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).