> If I understand correctly, the primary strength of the system you are
> working on is that it wastes less memory in satisfying allocation
> requests. As the user of a tiny little 8 meg machine, you can't
> imagine how much I look forward to getting my filthy hands on this
> code. ;)
Until a couple of months ago I was using a 386/33 with 4MB :-).
> However, the buddy system already does a good job of actually
> satisfying small-allocation requests, even if it wastes lots of the
> space it has available. That is to say, your new code has the effect
> of magically boosting the size of physical memory, but the actual
> failure rates of a "kmalloc(1024,GFP_KERNEL)" won't differ, even if
> that call is more likely to cause a page fault under the buddy system
> than under yours.
Small allocations, yes. The problem with buddy is that to make, say,
a block of 8 pages it needs to combine two neighbouring blocks of
4 pages and so on. This leads it to only allow certain alignments
of blocks which reduces the possibilities as you go to larger sizes
(and increases the wastage).
Note that I talked about page allocation above. For kmalloc it
seems better to forget about coalescing fragments. The dominant
kmalloc activity is at relatively small sizes so collecting fragments
is a good thing (when we get a completely free page in the free
lists we pull all the fragments and release the page - modulo a
small delay to avoid thrashing). For larger requests we just grab
more pages and peel off the fragment we want. With the lower size
queues being kept stuffed wih fragments we will have a tendency
to keep a few blocks on the active larger queues. It's like a
cascade through a meat grind - pages go in the top, get fragmented
as needed, and when the little bits drop out the bottom we just
sweep them up and recycle them. It's pretty much self balancing.
> However, even after your code is in the kernel, it will still be
> possible for a multipage allocation request to fail even though there
> are plenty of pages all over the place.
Even single page requests fail eventually :-). Code should be prepared
for things to fail. The likelyhood of something failing is inversely
proportional to the cost of making it work under extreme conditions.
As with everything we just have to do our best within the budget
available :-).
Of course, you can *already* use paging to "solve" the problem.
Simply ask for memory with GFP_ATOMIC (to avoid a thrash if the
request cannot trivially be satisfied) and if it fails use vmalloc
to map pages into kernel memory. But remember that remapped memory
is not always suitable - DMA...
Mike
-- .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk | | Roan Technology Ltd. | | | 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 | | RG40 1XG, ENGLAND | Fax: +44 118 989 1195 | `----------------------------------------------------------------------'