[lkml]   [1997]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.1.76, nfs client, and memory fragmentation
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

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.


 \ /
  Last update: 2005-03-22 13:40    [W:0.074 / U:8.112 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site