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

Martin J. Bligh
2005-10-31T14:34:30Z

>> Despite what people were trying to tell me at Ottawa, this patch
>> set really does add quite a lot of complexity to the page
>> allocator, and it seems to be increasingly only of benefit to
>> dynamically allocating hugepages and memory hot unplug.
>
> Remember that Rohit is seeing ~10% variation between runs of scientific
> software, and that his patch to use higher-order pages to preload the
> percpu-pages magazines fixed that up. I assume this means that it provided
> up to 10% speedup, which is a lot.

I, for one, would like to see some harder numbers on that, together with
which architectures they actually affect.

> But the patch caused page allocator fragmentation and several reports of
> gigE Tx buffer allocation failures, so I dropped it.

Yes, it made that condition worse but ...

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

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

We don't make a good job of doing long-term stress testing, which is
where fragmentation occurs. Unfortunately, customers do ;-(. I've become
fairly convinced we need something like this.

M.