Re: [patch 2/3] slub: scan partial list for free slabs when thrashing

From: David Rientjes <rientjes@google.com>
To: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Martin Bligh <mbligh@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [patch 2/3] slub: scan partial list for free slabs when thrashing
Date: Mon, 30 Mar 2009 13:22:55 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.00.0903301317120.21074@chino.kir.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0903301033380.13333@qirst.com>

On Mon, 30 Mar 2009, Christoph Lameter wrote:

> > Whenever a cpu cache satisfies a fastpath allocation, a fastpath counter
> > is incrememted.  This counter is cleared whenever the slowpath is
> > invoked.  This tracks how many fastpath allocations the cpu slab has
> > fulfilled before it must be refilled.
> 
> That adds fastpath overhead and it shows for small objects in your tests.
> 

Indeed, which is unavoidable in this case.  The only other way of tracking 
the "thrashing history" I can think of would be bitshifting a 1 for 
slowpath and 0 for fastpath, for example, into an unsigned long.  That, 
however, requires a hamming weight calculation in the slowpath and doesn't 
scale nearly as well as simply an incrementing a counter.

If there's other approaches on tracking such instances, I'd be interested 
to hear them.

Btw, is cl@linux.com your new email address or are all 
linux-foundation.org emails going to eventually migrate to the new domain?