[lkml]   [2002]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] linux-2.5.34_vsyscall_A0

> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:30    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean