linux-kernel - Re: [PATCH 3/7] mm: vmscan: Reclaim order-0 and use compaction instead of lumpy reclaim

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Dec 2010 10:56:49 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Johannes Weiner <hannes@...xchg.org>
Cc:	Andrea Arcangeli <aarcange@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/7] mm: vmscan: Reclaim order-0 and use compaction
	instead of lumpy reclaim

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@....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@...xchg.org>
> 

Thanks

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/