From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH 0/5] make slab gfp fair From: Peter Zijlstra In-Reply-To: References: <20070514131904.440041502@chello.nl> <20070514161224.GC11115@waste.org> <1179164453.2942.26.camel@lappy> <1179170912.2942.37.camel@lappy> <1179250036.7173.7.camel@twins> <1179298771.7173.16.camel@twins> <1179343521.2912.20.camel@lappy> <1179346738.2912.39.camel@lappy> <1179348039.2912.48.camel@lappy> <1179348898.2912.57.camel@lappy> <1179349494.2912.62.camel@lappy> Content-Type: text/plain Date: Wed, 16 May 2007 23:20:33 +0200 Message-Id: <1179350433.2912.66.camel@lappy> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Matt Mackall , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Thomas Graf , David Miller , Andrew Morton , Daniel Phillips , Pekka Enberg List-ID: On Wed, 2007-05-16 at 14:13 -0700, Christoph Lameter wrote: > On Wed, 16 May 2007, Peter Zijlstra wrote: > > > How we know that we are out of trouble? Just try another alloc and see? If > > > that is the case then we may be failing allocations after the memory > > > situation has cleared up. > > No, no, for each regular allocation we retry to populate ->cpu_slab with > > a new slab. If that works we're out of the woods and the ->reserve_slab > > is cleaned up. > > Hmmm.. so we could simplify the scheme by storing the last rank > somewheres. Not sure how that would help.. > If the alloc has less priority and we can extend the slab then > clear up the situation. > > If we cannot extend the slab then the alloc must fail. That is exactly what is done; and as mpm remarked the other day, its a binary system; we don't need full gfp fairness just ALLOC_NO_WATERMARKS. And that is already found in ->reserve_slab; if present the last allocation needed it; if not the last allocation was good. > Could you put the rank into the page flags? On 64 bit at least there > should be enough space. Current I stick the newly allocated page's rank in page->rank (yet another overload of page->index). I've not yet seen the need to keep it around longer. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org