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]
Message-ID: <20101118183448.GC30376@random.random>
Date:	Thu, 18 Nov 2010 19:34:48 +0100
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Mel Gorman <mel@....ul.ie>
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 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
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.

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ