From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [PATCH 3/5] Switch caches notification dynamically Date: Thu, 27 Sep 2007 12:24:09 +0400 Message-ID: <46FB68A9.2070100@openvz.org> References: <46F91841.9070708@openvz.org> <46F919BB.2000701@openvz.org> <46FA28C9.9060101@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 , Balbir Singh List-Id: containers.vger.kernel.org Christoph Lameter wrote: > On Wed, 26 Sep 2007, Pavel Emelyanov wrote: > >>> Is it necessary to mark all the existing slabs with SLAB_DEBUG? Would it >> Yup. Otherwise we can never receive a single event e.g. if we make >> alloc/free in a loop, or similar, so that new slabs simply are not >> created. > > Right but on the other hand: If objects in these slabs are freed then your > counters get decremented and may go negative. Nope :) I store a pointer on each accounted object, so if I have a notification about freeing of not-accounted object I will not decrement my counter ;) I think it's too hard (if possible at all) to handle at generic level whether we have notified this particular object allocation to some listener or not, so I'd better leave this for the listener to handle such a case. Thanks, Pavel