linux-kernel - Re: [PATCH 6/8] mm: compaction: Perform a faster scan in try_to_compact

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:	Thu, 18 Nov 2010 18:50:46 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Andrea Arcangeli <aarcange@...hat.com>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/8] mm: compaction: Perform a faster scan in
	try_to_compact_pages()

On Thu, Nov 18, 2010 at 07:34:48PM +0100, Andrea Arcangeli wrote:
> On Wed, Nov 17, 2010 at 04:22:47PM +0000, Mel Gorman wrote:
> > @@ -485,8 +500,8 @@ static unsigned long compact_zone_order(struct zone *zone,
> >  		.nr_migratepages = 0,
> >  		.order = order,
> >  		.migratetype = allocflags_to_migratetype(gfp_mask),
> > +		.migrate_fast_scan = true,
> >  		.zone = zone,
> > -		.sync = false,
> >  	};
> >  	INIT_LIST_HEAD(&cc.freepages);
> >  	INIT_LIST_HEAD(&cc.migratepages);
> > @@ -502,8 +517,8 @@ unsigned long reclaimcompact_zone_order(struct zone *zone,
> >  		.nr_migratepages = 0,
> >  		.order = order,
> >  		.migratetype = allocflags_to_migratetype(gfp_mask),
> > +		.migrate_fast_scan = false,
> >  		.zone = zone,
> > -		.sync = true,
> >  	};
> 
> Same as for the previous feature (sync/async migrate) I'd prefer if
> this was a __GFP_ flag (khugepaged will do the no-fast-scan version,
> page fault will only run compaction in fast scan mode) and if we

For THP in general, I think we can abuse __GFP_NO_KSWAPD. For other callers,
I'm not sure it's fair to push the responsibility of async/sync to them. We
don't do it for reclaim for example and I'd worry the wrong decisions would
be made or that they'd always select async for "performance" and then bitch
about an allocation failure.

> removed the reclaimcompact_zone_order and we stick with the
> interleaving of shrinker and try_to_compact_pages from the alloc_pages
> caller, with no nesting of compaction inside the shrinker.
> 
> Another possibility would be to not have those as __GFP flags, and to
> always do the first try_to_compact_pages with async+fast_scan, then
> call the shrinker and then all next try_to_compact_pages would be
> called with sync+no_fast_scan mode.
> 

I'll investigate this.

> But I love if we can further decrease the risk of too long page
> hugepage page fault before the normal page fallback, and to have a
> __GFP_ flag for these two. Even the same __GFP flag could work for
> both...
> 
> So my preference would be to nuke reclaimcompact_zone_order, only
> stick to compact_zone_order and the current interleaving, and add a
> __GFP_COMPACT_FAST used by the hugepmd page fault (that will enable
> both async migrate and fast-scan). khugepaged and hugetlbfs won't use
> __GFP_COMPACT_FAST.

My only whinge about the lack of reclaimcompact_zone_order is that it
makes it harder to even contemplate lumpy compaction in the future but
it could always be reintroduced if absolutely necessary.

> 
> I'm undecided if a __GFP_ flag is needed to differentiate the callers,
> or if we should just run the first try_to_compact_pages in
> "optimistic" mode by default.
> 

GFP flags would be my last preference. 

-- 
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/