[lkml]   [2005]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH 1/6] Create Critical Page Pool
    Hi Matthew,

    On Tue, Dec 13, 2005 at 11:52:46PM -0800, Matthew Dobson wrote:
    > Create the basic Critical Page Pool. Any allocation specifying
    > __GFP_CRITICAL will, as a last resort before failing the allocation, try to
    > get a page from the critical pool. For now, only singleton (order 0) pages
    > are supported.

    Hmm sorry, but this design looks wrong to me. Since the caller has to
    use __GFP_CRITICAL anyway, why don't you build this critical pool
    _outside_ the page allocator exactly like the mempool does?

    Then you will also get an huge advantage, that is allowing to create
    more than one critical pool without having to add a __GFP_CRITICAL2 next

    So IMHO if something you should create something like a mempool (if the
    mempool isn't good enough already for your usage), so more subsystems
    can register their critical pools. Call it criticalpool.c or similar but
    I wouldn't mess with __GFP_* and page_alloc.c, and the sysctl should be
    in the user subsystem, not global.

    Or perhaps you can share the mempool code and extend the mempool API to
    refill itself internally automatically as soon as pages are being

    You may still need a single hook in the __free_pages path, to refill
    pools transparently from any freeing (not only the freeing of your
    subsystem) but such an hook is acceptable. You may need to set
    priorities in the criticalpool.c api as well to choose which pool to
    refill first, or if to refill them in round robin when they've the same

    I would touch page_alloc.c only with regard of the prioritized pool
    refilling with a registration hook and I would definitely not use a
    global pool and I wouldn't use __GFP_ bitflag for it.

    Then each slab will be allowed to have its criticalpool too, then, not
    a global one. A global one driven by the __GFP_CRITICAL flag will
    quickly become useless as soon as you've more than one subsystem using
    it, plus it unnecessairly mess with page_alloc.c APIs where the only
    thing you care about is to catch the freeing operation with a hook.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-12-14 11:51    [W:0.023 / U:1.672 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site