Messages in this thread | | | Subject | Re: Avoiding external fragmentation with a placement policy Version 12 | From | Nick Piggin <> | Date | Fri, 03 Jun 2005 13:48:08 +1000 |
| |
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/
| |