Re: 2.6.16-rc6-mm2

[Andi Kleen <ak@suse.de>]

> i think you are right - but if someone goes the trouble of implementing 
> per-arch support for local increments then i'm not against it. (except 
> if the generated code is grossly inefficient) There are architectures 
> where cli/sti hurts alot.

I was refering to asm-generic/local.h

> 
> In any case, on x86 we should switch to a cli/sti implementation indeed 

x86 doesn't need it IMHO - as long as the RMW is atomic as seen by the local
CPU it's ok to use a stale per CPU variable here. So using raw_smp_processor_id()
for this is ok.

> 
> Although on x86_64 we'd probably be pretty OK if all per-cpu variables 
> were in the PDA and were thus at a constant %gs-relative offset. But for 
> now we only have data_offset in the PDA so there's one more unnecessary 
> indirection.

I looked at this some time ago. The problem is that it would require
new relocation types implemented in the assembler/linker. So I kept
the current implementation.

But even the current code is ok because the access is atomic towards
the local CPU. If it's out of date by two cycles on preempt it doesn't
matter much.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/