Re: 2.6.16-rc6-mm2


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/