Re: [RFC][PATCH] linux-2.5.34_vsyscall_A0

[Stephen Hemminger <shemminger@osdl.org>]

> agreed. Hear my idea:
> 
> 	actually my idea on 64bit was to use the high 8 bit of each 64bit word to
> 	give you the cpuid, to get out the coherent data, including the sequence
> 	number that are read and written inversely with mb() like now (the
> 	sequence number as well will become per-cpu), so it is definitely doable
> 	without any single problem and in a very performant way, just not as
> 	easy as without the per-cpu info. Even if segmentation per-cpu tricks
> 	would be possible or available (remeber long mode is pure paging, no
> 	segmentation) it would be not worthwhile IMHO, the cpuid encoded
> 	atomically in each 64bit data provided by the vsyscall seems a much
> 	simpler and possibly more performant solution. You set a different
> 	per-cpu data-mapping with different pte settings in each cpu. The
> 	vsyscall bytecode remains the same, aware about this cpuid encoded in
> 	each 64bit word. Doing it in 32bit is ugly (or at least much slower)
> 	since most data is natively at least 32bit, it would need some slow
> 	demultiplexing.

At least on IA32 you could still use XCHG64 to atomically access the
values, but that always forces a write so it isn't cache friendly. Still
it probably is better than encoding the data in 32bit.  It all depends
on how much data is needed.