Re: Avoiding external fragmentation with a placement policy Version 12

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Thu, 2005-06-02 at 10:52 -0500, Joel Schopp wrote:
> > I see your point... Mel's patch has failure cases though.
> > For example, someone turns swap off, or mlocks some memory
> > (I guess we then add the page migration defrag patch and
> > problem is solved?).
> 
> This reminds me that page migration defrag will be pretty useless 
> without something like this done first.  There will be stuff that can't 
> be migrated and it needs to be grouped together somehow.
> 
> In summary here are the reasons I see to run with Mel's patch:
> 
> 1. It really helps with medium-large allocations under memory pressure.
> 2. Page migration defrag will need it.
> 3. Memory hotplug remove will need it.
> 

I guess I'm now more convinced of its need ;)

add:
4. large pages
5. (hopefully) helps with smaller allocations (ie. order 3)

It would really help your cause in the short term if you can
demonstrate improvements for say order-3 allocations (eg. use
gige networking, TSO, jumbo frames, etc).


> On the downside we have:
> 
> 1. Slightly more complexity in the allocator.
> 

For some definitions of 'slightly', perhaps :(

Although I can't argue that a buddy allocator is no good without
being able to satisfy higher order allocations.

So in that case, I'm personally OK with it going into -mm. Hopefully
there will be a bit more review and hopefully some simplification if
possible.

Last question: how does it go on systems with really tiny memories?
(4MB, 8MB, that kind of thing).

> I'd personally trade a little extra complexity for any of the 3 upsides.
> 

-- 
SUSE Labs, Novell Inc.




Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/