From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by ug-out-1314.google.com with SMTP id s2so1095249uge for ; Wed, 21 Feb 2007 07:48:00 -0800 (PST) Message-ID: <84144f020702210747t50d7d92ei1a2f5da8bf117d40@mail.gmail.com> Date: Wed, 21 Feb 2007 17:47:59 +0200 From: "Pekka Enberg" Subject: Re: [PATCH 08/29] mm: kmem_cache_objs_to_pages() In-Reply-To: <20070221144842.299190000@taijtu.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070221144304.512721000@taijtu.programming.kicks-ass.net> <20070221144842.299190000@taijtu.programming.kicks-ass.net> Sender: owner-linux-mm@kvack.org Return-Path: To: Peter Zijlstra Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, Trond Myklebust , Thomas Graf , David Miller List-ID: Hi Peter, On 2/21/07, Peter Zijlstra wrote: > Provide a method to calculate the number of pages needed to store a given > number of slab objects (upper bound when considering possible partial and > free slabs). So how does this work? You ask the slab allocator how many pages you need for a given number of objects and then those pages are available to it via the page allocator? Can other users also dip into those reserves? I would prefer we simply have an API for telling the slab allocator to keep certain number of pages in a reserve for a cache rather than exposing internals such as object size to rest of the world. 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