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> Content-Type: text/plain Date: Wed, 16 May 2007 08:59:31 +0200 Message-Id: <1179298771.7173.16.camel@twins> 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 Tue, 2007-05-15 at 15:02 -0700, Christoph Lameter wrote: > On Tue, 15 May 2007, Peter Zijlstra wrote: > > > How about something like this; it seems to sustain a little stress. > > Argh again mods to kmem_cache. Hmm, I had not understood you minded that very much; I did stay away from all the fast paths this time. The thing is, I wanted to fold all the emergency allocs into a single slab, not a per cpu thing. And once you loose the per cpu thing, you need some extra serialization. Currently the top level lock is slab_lock(page), but that only works because we have interrupts disabled and work per cpu. Why is it bad to extend kmem_cache a bit? -- 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