From: Andi Kleen <[EMAIL PROTECTED]>
Date: Tue, 20 Nov 2007 04:25:34 +0100
>
> > Although we have a per-cpu area base in a fixed global register
> > for addressing, the above isn't beneficial on sparc64 because
> > the atomic is much slower than doing a:
> >
> > local_irq_disable();
> >
n Tue, 20 Nov 2007, Andi Kleen wrote:
>
> > Although we have a per-cpu area base in a fixed global register
> > for addressing, the above isn't beneficial on sparc64 because
> > the atomic is much slower than doing a:
> >
> > local_irq_disable();
> > nonatomic_percpu_memory_op();
> >
> Although we have a per-cpu area base in a fixed global register
> for addressing, the above isn't beneficial on sparc64 because
> the atomic is much slower than doing a:
>
> local_irq_disable();
> nonatomic_percpu_memory_op();
> local_irq_enable();
Again might be pointing out
On Mon, 19 Nov 2007, David Miller wrote:
> From: Christoph Lameter <[EMAIL PROTECTED]>
> Date: Mon, 19 Nov 2007 17:59:33 -0800 (PST)
>
> > In that case the generic fallbacks can just provide what you already
> > have.
>
> I understand, I was just letting you know why we probably won't
> take
From: Christoph Lameter <[EMAIL PROTECTED]>
Date: Mon, 19 Nov 2007 17:59:33 -0800 (PST)
> In that case the generic fallbacks can just provide what you already
> have.
I understand, I was just letting you know why we probably won't
take advantage of this new stuff :-)
-
To unsubscribe from this
On Mon, 19 Nov 2007, David Miller wrote:
> Although we have a per-cpu area base in a fixed global register
> for addressing, the above isn't beneficial on sparc64 because
> the atomic is much slower than doing a:
>
> local_irq_disable();
> nonatomic_percpu_memory_op();
>
From: [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 17:11:32 -0800
> Before:
>
> mov%gs:0x8,%rdx Get smp_processor_id
> movtableoffset,%rax Get table base
> incq varoffset(%rax,%rdx,1) Perform the operation with a complex lookup
> adding
Duh a patch did not make it due to XXX in the header.
I will put this also on git.kernel.org slab tree branch cpudata
x86_64: Strip down PDA operations through the use of CPU_XXX operations.
The *_pda operations behave in the same way as the CPU_XX ops. They both access
data
that is relative
Duh a patch did not make it due to XXX in the header.
I will put this also on git.kernel.org slab tree branch cpudata
x86_64: Strip down PDA operations through the use of CPU_XXX operations.
The *_pda operations behave in the same way as the CPU_XX ops. They both access
data
that is relative
From: [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 17:11:32 -0800
Before:
mov%gs:0x8,%rdx Get smp_processor_id
movtableoffset,%rax Get table base
incq varoffset(%rax,%rdx,1) Perform the operation with a complex lookup
adding the
On Mon, 19 Nov 2007, David Miller wrote:
Although we have a per-cpu area base in a fixed global register
for addressing, the above isn't beneficial on sparc64 because
the atomic is much slower than doing a:
local_irq_disable();
nonatomic_percpu_memory_op();
From: Christoph Lameter [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 17:59:33 -0800 (PST)
In that case the generic fallbacks can just provide what you already
have.
I understand, I was just letting you know why we probably won't
take advantage of this new stuff :-)
-
To unsubscribe from this list:
On Mon, 19 Nov 2007, David Miller wrote:
From: Christoph Lameter [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 17:59:33 -0800 (PST)
In that case the generic fallbacks can just provide what you already
have.
I understand, I was just letting you know why we probably won't
take advantage of
Although we have a per-cpu area base in a fixed global register
for addressing, the above isn't beneficial on sparc64 because
the atomic is much slower than doing a:
local_irq_disable();
nonatomic_percpu_memory_op();
local_irq_enable();
Again might be pointing out the
n Tue, 20 Nov 2007, Andi Kleen wrote:
Although we have a per-cpu area base in a fixed global register
for addressing, the above isn't beneficial on sparc64 because
the atomic is much slower than doing a:
local_irq_disable();
nonatomic_percpu_memory_op();
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 20 Nov 2007 04:25:34 +0100
Although we have a per-cpu area base in a fixed global register
for addressing, the above isn't beneficial on sparc64 because
the atomic is much slower than doing a:
local_irq_disable();
16 matches
Mail list logo
