lkml.org 
[lkml]   [2000]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: the new VMt
yodaiken@fsmlabs.com wrote:
> > Or go the beancounter route: process 1 asks "can I pin 20 pages", gets
> > told "yes", and goes allocating them, blocking as necessary until it
>
> So you have a "pre-allocation allocator"? Leads to interesting and
> hard to detect bugs with old code that does not pre-allocate or with
> code that incorrectly pre-allocates or that blocks on something
> unrelated

I agree with Victor. Relying on code that calls gfp to do the correct
accounting in advance, to avoid deadlocks, is not at all robust. Even
the best programmers will have off by one errors in that, and the rest
of us will blindly write code that works all the time, except for the
really obscure case when it fails.

Ideally do both: see if you can allocate in advance, then try it,
but be prepared to back off and return ENOMEM if that fails.

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

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.348 / U:3.420 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site