From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [RFC][PATCH 0/3] Kernel memory accounting container (v2) Date: Mon, 17 Sep 2007 10:12:47 +0400 Message-ID: <46EE1ADF.7090201@openvz.org> References: <46E8FEC7.2010707@openvz.org> <46EA297B.5070605@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Christoph Lameter Cc: Linux Containers , Paul Menage List-Id: containers.vger.kernel.org Christoph Lameter wrote: > On Fri, 14 Sep 2007, Pavel Emelyanov wrote: > >>> Hmmmm... Okay I have seen multiple people who want to control slab >>> allocations and track memory for various reasons. Would it be possible to >>> come up with some hook that would allow a subscription to certain SLUB >>> events? That way multiple subsystems may track and maybe disallow certain >>> allocations in various contexts. >> Do you mean some more generic than just explicit call from slab_alloc, etc? >> Ok, I will work on it. > > Yes I guess an API in slub to register callbacks for these things. This > needs to include a way to control the granularity. Callbacks at the level > of slab allocations are likely not that performance critical. But some > uses may require control at the object level. There needs to be some way > to tell SLUB to disable the fast path for a particular allocated slab > because the API will police each individual allocation. > OK. I see. I will do my best to prepare the first version this week. Thanks, Pavel