From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 4 May 2007 12:59:44 -0700 (PDT) From: Christoph Lameter Subject: Re: [PATCH 08/40] mm: kmem_cache_objsize In-Reply-To: <463B815E.8010806@cs.helsinki.fi> Message-ID: References: <20070504102651.923946304@chello.nl> <20070504103157.215424767@chello.nl> <1178301545.24217.56.camel@twins> <1178302904.2767.6.camel@lappy> <1178303538.2767.9.camel@lappy> <463B7F63.8070508@cs.helsinki.fi> <463B815E.8010806@cs.helsinki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Pekka Enberg Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, Trond Myklebust , Thomas Graf , David Miller , James Bottomley , Mike Christie , Andrew Morton , Daniel Phillips List-ID: On Fri, 4 May 2007, Pekka Enberg wrote: > Christoph Lameter wrote: > > On Fri, 4 May 2007, Pekka Enberg wrote: > > > > > Again, slab has no way of actually estimating how many pages you need for > > > a > > > given number of objects. So we end up calculating some upper bound which > > > doesn't belong in mm/slab.c. I am perfectly okay with: > > > > It can give a worst case number and that is what he wants. > > Sure. But he can calculate that elsewhere instead of bringing it in mm/slab.c > where it's no use for anyone else... He is not able to calculate it just using the object size since he does not know where the slab put the slab management structure. And in case of SLUB there is no slab management structure... Which means he would have to special case based on the slab allocator selected. -- 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