Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

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

Martin J. Bligh wrote:

>>We think that Mel's patches will allow us to reintroduce Rohit's
>>optimisation.
> 
> 
> ... frankly, it happens without Rohit's patch as well (under more stress).
> If we want a OS that is robust, and supports higher order allocations,
> we need to start caring about fragmentations. Not just for large pages,
> and hotplug, but also for more common things like jumbo GigE frames,
> CIFS, various device drivers, kernel stacks > 4K etc. 
> 

But it doesn't seem to be a great problem right now, apart from hotplug
and hugepages. Some jumbo GigE drivers use higher order allocations, but
I think there are moves to get away from that (e1000, for example).

> To me, the question is "do we support higher order allocations, or not?".
> Pretending we do, making a half-assed job of it, and then it not working
> well under pressure is not helping anyone. I'm told, for instance, that
> AMD64 requires > 4K stacks - that's pretty fundamental, as just one 

And i386 had required 8K stacks for a long long time too.

> instance. I'd rather make Linux pretty bulletproof - the added feature
> stuff is just a bonus that comes for free with that.
> 

But this doesn't exactly make Linux bulletproof, AFAIKS it doesn't work
well on small memory systems, and it can still get fragmented and not work.
IMO in order to make Linux bulletproof, just have fallbacks for anything
greater than about order 2 allocations.

 From what I have seen, by far our biggest problems in the mm are due to
page reclaim, and these patches will make our reclaim behaviour more
complex I think.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>