Messages in this thread |  | | Date | Mon, 25 Sep 2000 20:48:06 +0200 | From | Jamie Lokier <> | Subject | Re: 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/
|  |