Re: [patch 0/6] Per cpu structures for SLUB

2007-08-27 Thread Andrew Morton
On Mon, 27 Aug 2007 11:50:10 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Fri, 24 Aug 2007, Andrew Morton wrote: > > > I'm struggling a bit to understand these numbers. Bigger is better, I > > assume? In what units are these numbers? > > No less is better. These are cycle coun

Re: [patch 0/6] Per cpu structures for SLUB

2007-08-27 Thread Christoph Lameter
On Fri, 24 Aug 2007, Andrew Morton wrote: > I'm struggling a bit to understand these numbers. Bigger is better, I > assume? In what units are these numbers? No less is better. These are cycle counts. Hmmm... We discussed these cycle counts so much in the last week that I forgot to mention that

Re: [patch 0/6] Per cpu structures for SLUB

2007-08-24 Thread Andrew Morton
On Wed, 22 Aug 2007 23:46:53 -0700 Christoph Lameter <[EMAIL PROTECTED]> wrote: > The following patchset introduces per cpu structures for SLUB. These > are very small (and multiples of these may fit into one cacheline) > and (apart from performance improvements) allow the addressing of > several

Re: [patch 0/6] Per cpu structures for SLUB

2007-08-23 Thread Christoph Lameter
On Thu, 23 Aug 2007, Peter Zijlstra wrote: > while I like this patch set I'm at odds with the interaction of this and > making the alloc/free fast paths lockless. > > The main race is s->cpu_slab[] and c->freelist. How does one close that > gap? By either reloading the cpu slab after disabling

Re: [patch 0/6] Per cpu structures for SLUB

2007-08-23 Thread Peter Zijlstra
Hi, while I like this patch set I'm at odds with the interaction of this and making the alloc/free fast paths lockless. The main race is s->cpu_slab[] and c->freelist. How does one close that gap? (btw, have you looked at my -rt slub patch?) - To unsubscribe from this list: send the line "unsu