lkml.org 
[lkml]   [2007]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 00/10] foundations for reserve-based allocation
Date
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.

Regards,

Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-08-06 21:55    [W:0.094 / U:0.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site