[lkml]   [2007]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/10] foundations for reserve-based allocation
    On Monday 06 August 2007 12:36, Peter Zijlstra wrote:
    > On Mon, 2007-08-06 at 12:31 -0700, Daniel Phillips wrote:
    > > On Monday 06 August 2007 11:17, Peter Zijlstra wrote:
    > > > And how do we know a page was taken out of the reserves?
    > >
    > > Why not return that in the low bit of the page address? This is a
    > > little more cache efficient, does not leave that odd footprint in
    > > the page union and forces the caller to examine the
    > > alloc_pages(...P_MEMALLOC) return, making it harder to overlook the
    > > fact that it got a page out of reserve and forget to put one back
    > > later.
    > This would require auditing all page allocation sites to ensure they
    > ever happen under PF_MEMALLOC or the like. Because if an allocator
    > ever fails to check the low bit and assumes its a valid struct page
    > *, stuff will go *bang*.

    But is that not exactly what we want? If somebody sets __GFP_MEMALLOC
    then they had better be prepared to deal with the result.

    OK, I see there are cases where the the gfp flags are blindly passed
    down level after level (tending to indicate a design flaw anyway) but
    they usually also get passed back up the chain without examination.
    Yes, an audit would be needed, but since when has that ever stood in
    the way of a miniscule optimization? And if we miss a case it
    helpfully goes bang on us, no need to play games with new function
    names or the like.


    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: 2007-08-06 21:55    [W:0.035 / U:1.076 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site