Re: Avoiding external fragmentation with a placement policy Version 12

Nick Piggin
2005-06-03T03:48:08Z

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