From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <463B7E5C.8030201@cs.helsinki.fi> Date: Fri, 04 May 2007 21:41:32 +0300 From: Pekka Enberg MIME-Version: 1.0 Subject: Re: [PATCH 08/40] mm: kmem_cache_objsize References: <20070504102651.923946304@chello.nl> <20070504103157.215424767@chello.nl> <1178301545.24217.56.camel@twins> <1178302904.2767.6.camel@lappy> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter 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: Christoph Lameter wrote: > Hmmm... Maybe lets have > > unsigned kmem_estimate_pages(struct kmem_cache *slab_cache, int objects) > > which would calculate the worst case memory scenario for allocation the > number of indicated objects? IIRC this looks more or less what Peter had initially. I don't like the API because there's no way for slab (perhaps this is different for slub) how many pages you really need due to per-node and per-cpu caches, etc. It's better that the slab tells you what it actually knows and lets the callers figure out what a worst-case upper bound is. Pekka -- 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