lkml.org 
[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
    From
    Date

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

    \
     
     \ /
      Last update: 2005-03-22 13:30    [W:0.040 / U:88.904 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site