Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762311AbXHTUJv (ORCPT ); Mon, 20 Aug 2007 16:09:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761593AbXHTUJ2 (ORCPT ); Mon, 20 Aug 2007 16:09:28 -0400 Received: from pentafluge.infradead.org ([213.146.154.40]:59688 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761396AbXHTUJY (ORCPT ); Mon, 20 Aug 2007 16:09:24 -0400 Subject: Re: [PATCH 04/10] mm: slub: add knowledge of reserve pages From: Peter Zijlstra To: Christoph Lameter Cc: Pekka Enberg , linux-kernel@vger.kernel.org, linux-mm@kvack.org, David Miller , Andrew Morton , Daniel Phillips , Matt Mackall , Lee Schermerhorn , Steve Dickson In-Reply-To: References: <20070806102922.907530000@chello.nl> <20070806103658.603735000@chello.nl> <1187595513.6114.176.camel@twins> <1187601455.6114.189.camel@twins> <84144f020708200228v1af5248cx6f6da4a7a35400f3@mail.gmail.com> Content-Type: text/plain Date: Mon, 20 Aug 2007 22:08:53 +0200 Message-Id: <1187640533.5337.27.camel@lappy> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2397 Lines: 58 On Mon, 2007-08-20 at 12:26 -0700, Christoph Lameter wrote: > On Mon, 20 Aug 2007, Pekka Enberg wrote: > > > Hi Peter, > > > > On Mon, 2007-08-20 at 12:12 +0300, Pekka J Enberg wrote: > > > > Any reason why the callers that are actually interested in this don't do > > > > page->reserve on their own? > > > > On 8/20/07, Peter Zijlstra wrote: > > > because new_slab() destroys the content? > > > > Right. So maybe we could move the initialization parts of new_slab() > > to __new_slab() so that the callers that are actually interested in > > 'reserve' could do allocate_slab(), store page->reserve and do rest of > > the initialization with it? > > I am still not convinced about this approach and there seems to be > agreement that this is not working on large NUMA. So #ifdef it out? > !CONFIG_NUMA? Some more general approach that does not rely on a single > slab being a reserve? See the patch I sent earlier today? > The object is to check the alloc flags when having allocated a reserve > slab right? The initial idea was to make each slab allocation respect the watermarks like page allocation does (the page rank thingies, if you remember). That is if the slab is allocated from below the ALLOC_MIN|ALLOC_HARDER threshold, an ALLOC_MIN|ALLOC_HIGH allocation would get memory, but an ALLOC_MIN would not. Now, we only needed the ALLOC_MIN|ALLOC_HIGH|ALLOC_HARDER <-> ALLOC_NO_WATERMARKS transition and hence fell back to a binary system that is not quite fair wrt to all the other levels but suffices for the problem at hand. So we want to ensure that slab allocations that are _not_ entitled to ALLOC_NO_WATERMARK memory will not get objects when a page allocation with the same right would fail, even if there is a slab present. > Adding another flag SlabReserve and keying off on that one may > be the easiest solution. Trouble with something like that is that page flags are peristent and you'd need to clean them when the status flips -> O(n) -> unwanted. > I have pending patches here that add per cpu structures. Those will make > that job easier. Yeah, I've seen earlier versions of those. - 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/