From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [PATCH 3/5] Switch caches notification dynamically Date: Wed, 26 Sep 2007 13:39:21 +0400 Message-ID: <46FA28C9.9060101@openvz.org> References: <46F91841.9070708@openvz.org> <46F919BB.2000701@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 Tue, 25 Sep 2007, Pavel Emelyanov wrote: > >> + for_each_node_state(n, N_NORMAL_MEMORY) { >> + struct kmem_cache_node *node; >> + struct page *pg; >> + >> + node = get_node(s, n); >> + spin_lock_irq(&node->list_lock); >> + list_for_each_entry(pg, &node->partial, lru) >> + SetSlabDebug(pg); >> + spin_unlock_irq(&node->list_lock); > > > 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. > not be sufficient to just mark the new ones coming up? The above operation > could be a bit expensive. Oh, that's OK from my POV - switching slabs mode was never supposed to be a fast path. Thanks, Pavel