linux-kernel - Re: [PATCH 00/35] Cleanup and optimise the page allocator V3

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: <20090316155342.GH30802@wotan.suse.de>
Date:	Mon, 16 Mar 2009 16:53:42 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Linux Memory Management List <linux-mm@...ck.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Rik van Riel <riel@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lin Ming <ming.m.lin@...el.com>,
	Zhang Yanmin <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 00/35] Cleanup and optimise the page allocator V3

On Mon, Mar 16, 2009 at 01:32:32PM +0000, Mel Gorman wrote:
> On Mon, Mar 16, 2009 at 01:25:05PM +0100, Nick Piggin wrote:
> > > Well, buddy always uses the smallest available page first. Even with
> > > deferred coalescing, it will merge up to order-5 at least. Lets say they
> > > could have merged up to order-10 in ordinary circumstances, they are
> > > still avoided for as long as possible. Granted, it might mean that an
> > > order-5 is split that could have been merged but it's hard to tell how
> > > much of a difference that makes.
> > 
> > But the kinds of pages *you* are interested in are order-10, right?
> > 
> 
> Yes, but my expectation is that multiple free order-5 pages can be
> merged to make up an order-10.

Yes, but lazy buddy will give out part of an order-10 free area
to an order-5 request even when there are genuine order-5,6,7,8,9
free areas available.

Now it could be assumed that not too much else in the kernel
asks for anything over order-3, so you are unlikely to get these
kinds of requests. But it's worse than that actually, because
lazy buddy will also split half of an order-10 free area in order
to satisfy an order-0 allocation in cases that there are no smaller
orders than 5 available.

So yes definitely I think there should be a very real impact on
higher order coalescing no matter what you do.

> If they can't, then lumpy reclaim kicks
> in as normal. My expectation actually is that order-10 allocations often
> end up using lumpy reclaim and the pages are not automatically
> available.

movable zone is less interesting, although it will make it harder
to allocate these guys from movable zone. But the pages are
movable so eventually they should be able to be reclaimed.

unmovable zone fragmentation is more important point because it
eventually can destroy the movable zone.

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