[lkml]   [2008]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH] greatly reduce SLOB external fragmentation
    On Thu, 10 Jan 2008, Linus Torvalds wrote:

    > It's not even clear that a buddy allocator even for the high-order pages
    > is at all the right choice. Almost nobody actually wants >64kB blocks, and
    > the ones that *do* want bigger allocations tend to want *much* bigger
    > ones, so it's quite possible that it could be worth it to have something
    > like a three-level allocator:

    Excellent! I am definitely on board with this.

    > - huge pages (superpages for those crazy db people)
    > Just a simple linked list of these things is fine, we'd never care
    > about coalescing large pages together anyway.
    > - "large pages" (on the order of ~64kB) - with *perhaps* a buddy bitmap
    > setup to try to coalesce back into huge-pages, but more likely just
    > admitting that you'd need something like migration to ever get back a
    > hugepage that got split into large-pages.
    > So maybe a simple bitmap allocator per huge-page for large pages. Say
    > you have a 4MB huge-page, and just a 64-bit free-bitmap per huge-page
    > when you split it into large pages.
    > - slab/slub/slob for anything else, and "get_free_page()" ends up being
    > just a shorthand for saying "naturally aligned kmalloc of size
    > "PAGE_SIZE<<order"
    > and maybe it would all work out ok.

    Hmmm... a 3 level allocator? Basically we would have BASE_PAGE
    STANDARD_PAGE and HUGE_PAGE? We could simply extend the page allocator to
    have 3 pcp lists for these sizes and go from there?

    Thinking about the arches this would mean

    x86_64 4k 64k 2M
    i386 4k 16k 4M
    ia64 16k 256k 1G


     \ /
      Last update: 2008-01-10 20:49    [W:0.035 / U:16.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site