> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
