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
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
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.
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 counts.
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
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 isues
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
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
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 isues in SLUB:
1. The number of objects per slab is no longer limited to a 16 bit
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 isues in SLUB:
1. The number of objects per slab is no longer limited to a 16 bit
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
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
12 matches
Mail list logo
