Messages in this thread | | | Subject | Re: 2.1.76, nfs client, and memory fragmentation | Date | Sun, 28 Dec 1997 16:28:33 -0600 (CST) | From | kwrohrer@enteract ... |
| |
And lo, Alan Cox saith unto me: > > Well, yes, there's 1<<order pages in the free group whose buddy I'd be trying > > to free, and thus 1<<order pages of buddy... Making an order-d hunk of > > free pages may well be an O(order-d) operation, but shouldn't be worse than > > that, I'd hope... > Given a buddy system a single 1 page allocation that isnt freeable blocks > a 2K, 4K, 8K, 16K, 32K and 64K block and so on. Buddy is about the most > non optimal algorithm for creating large allocation spaces. However, permanently non-freeable blocks should be rare, temporarily locked blocks should be uncommon, and relocatable (= swappable) blocks should abound. And with a defragmenter available, especially one which can defragment to order (individual order, that is), the long-term kernel allocations can be made larger (and correspondingly less frequent), thereby minimizing the fragmentation.
> True its very very fast but now we have SLAB handling the small allocations > we should ditch the buddy allocator IMHO for something more intelligent, or > even something really stupid like first fit. Both will do better than it First fit and binary buddy are not exclusive; moreover, binary buddies offer rather fast rejoin operations (see mm/page_alloc.c:free_pages_ok). If we really want to rip out (or fiddle with) the low-level allocation code, we could do something to weight userspace pages towards the high (non-ISA-DMA capable, in case it matters) end of memory, while locked (kernel and kernel dynamic data) pages gravitate towards the boundary between DMA and non-DMA memory (with pages going on the DMA side if they need it or if we need the room).
However, none of these plans actually deals with fragmentation in any way, they just run a little farther and pray the fragmentation doesn't follow. Problem is, it *will* catch up one day. I'd just as soon shoot it now, so we can make larger allocations, then actually do something to make them happen should they block.
Keith
| |