linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rik van Riel <riel@redhat.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/7] mm: vmscan: Reclaim order-0 and use compaction instead of lumpy reclaim
Date: Wed, 1 Dec 2010 10:56:49 +0000	[thread overview]
Message-ID: <20101201105648.GM13268@csn.ul.ie> (raw)
In-Reply-To: <20101201102745.GL15564@cmpxchg.org>

On Wed, Dec 01, 2010 at 11:27:45AM +0100, Johannes Weiner wrote:
> On Mon, Nov 22, 2010 at 03:43:51PM +0000, Mel Gorman wrote:
> > Lumpy reclaim is disruptive. It reclaims a large number of pages and ignores
> > the age of the pages it reclaims. This can incur significant stalls and
> > potentially increase the number of major faults.
> > 
> > Compaction has reached the point where it is considered reasonably stable
> > (meaning it has passed a lot of testing) and is a potential candidate for
> > displacing lumpy reclaim. This patch introduces an alternative to lumpy
> > reclaim whe compaction is available called reclaim/compaction. The basic
> > operation is very simple - instead of selecting a contiguous range of pages
> > to reclaim, a number of order-0 pages are reclaimed and then compaction is
> > later by either kswapd (compact_zone_order()) or direct compaction
> > (__alloc_pages_direct_compact()).
> > 
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> 
> > @@ -286,18 +290,20 @@ static void set_lumpy_reclaim_mode(int priority, struct scan_control *sc,
> >  	lumpy_mode syncmode = sync ? LUMPY_MODE_SYNC : LUMPY_MODE_ASYNC;
> >  
> >  	/*
> > -	 * Some reclaim have alredy been failed. No worth to try synchronous
> > -	 * lumpy reclaim.
> > +	 * Initially assume we are entering either lumpy reclaim or
> > +	 * reclaim/compaction.Depending on the order, we will either set the
> > +	 * sync mode or just reclaim order-0 pages later.
> >  	 */
> > -	if (sync && sc->lumpy_reclaim_mode & LUMPY_MODE_SINGLE)
> > -		return;
> > +	if (COMPACTION_BUILD)
> > +		sc->lumpy_reclaim_mode = LUMPY_MODE_COMPACTION;
> > +	else
> > +		sc->lumpy_reclaim_mode = LUMPY_MODE_CONTIGRECLAIM;
> 
> Isn't this a regression for !COMPACTION_BUILD in that earlier kernels
> would not do sync lumpy reclaim when somebody disabled it during the
> async run?
> 

You'll need to clarify your question I'm afraid. In 2.6.36 for example,
if lumpy reclaim gets disabled then sync reclaim does not happen at all.
This was due to large stalls being observed when copying large amounts
of data to slow storage such as a USB external drive.

> If so, it should be trivial to fix.  Aside from that
> 
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
> 

Thanks

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-12-01 10:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-22 15:43 [PATCH 0/7] Use memory compaction instead of lumpy reclaim during high-order allocations V2 Mel Gorman
2010-11-22 15:43 ` [PATCH 1/7] mm: compaction: Add trace events for memory compaction activity Mel Gorman
2010-11-22 15:43 ` [PATCH 2/7] mm: vmscan: Convert lumpy_mode into a bitmask Mel Gorman
2010-12-01 10:27   ` Johannes Weiner
2010-12-01 10:50     ` Mel Gorman
2010-12-01 11:21       ` Johannes Weiner
2010-12-01 11:56         ` Mel Gorman
2010-12-02 11:04           ` Johannes Weiner
2010-12-02 12:03     ` [PATCH] mm: vmscan: Rename lumpy_mode to reclaim_mode fix Mel Gorman
2010-11-22 15:43 ` [PATCH 3/7] mm: vmscan: Reclaim order-0 and use compaction instead of lumpy reclaim Mel Gorman
2010-12-01 10:27   ` Johannes Weiner
2010-12-01 10:56     ` Mel Gorman [this message]
2010-12-01 11:32       ` Johannes Weiner
2010-11-22 15:43 ` [PATCH 4/7] mm: migration: Allow migration to operate asynchronously and avoid synchronous compaction in the faster path Mel Gorman
2010-12-01 10:28   ` Johannes Weiner
2010-11-22 15:43 ` [PATCH 5/7] mm: migration: Cleanup migrate_pages API by matching types for offlining and sync Mel Gorman
2010-12-01 10:28   ` Johannes Weiner
2010-11-22 15:43 ` [PATCH 6/7] mm: compaction: Perform a faster migration scan when migrating asynchronously Mel Gorman
2010-12-01 10:31   ` Johannes Weiner
2010-11-22 15:43 ` [PATCH 7/7] mm: vmscan: Rename lumpy_mode to reclaim_mode Mel Gorman
2010-12-01 10:34   ` Johannes Weiner
2010-11-22 16:01 ` [PATCH 0/7] Use memory compaction instead of lumpy reclaim during high-order allocations V2 Andrea Arcangeli

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=20101201105648.GM13268@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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).