On Sun, 5 Sep 2004, Nick Piggin wrote:
So my solution? Just teach kswapd and the watermark code about higher
order allocations in a fairly simple way. If pages_low is (say), 1024KB,
we now also require 512KB of order-1 and above pages, 256K of order-2
and up, 128K of order 3, etc. (perhaps we should stop at about order-3?)
I'm pretty sure we did something like this (where we not only required a
certain amount of memory free, but also a certain buddy availability) for
a short while in the 2.3.x timeframe or something like that, and that it
caused problems for some machines that just kept on trying to free memory.
I wrote a program at the time to check why, but I've long since lost it, so I re-created it just now (probably buggy as hell), and append it here for you to debug the dang thing.
In it's first rough draft (ie "it might be totally wrong") using this script:
Now, this test-result is not "real life", in that the whole point of the buddy allocator is that it is good at trying to keep higher orders free, and as such real life should behave much better. But this _is_ pretty accurate for the case where we totally ran out of memory and are trying
to randomly free one page here and one page there. That's where buddy doesn't much help us, so this kind of shows the worst case.
(Rule: you should not allow the machine to get to this point, exactly because at the < ~5% free point, buddy stops being very effective).
Notice how you may need to free 20% of memory to get a 2**3 allocation, if you have totally depleted your pages. And it's much worse if you have very little memory to begin with.
Anyway. I haven't debugged this program, so it may have serious bugs, and be off by an order of magnitude or two. Whatever. If I'm wrong, somebody can fix the program/script and see what the real numbers are.