[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.019 / U:5.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site