[lkml]   [2008]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectUse of barriers in pvclock ABI
    In Xen, we guarantee that the pv clock record will only ever be updated 
    by the current cpu, so there will never be any cross-cpu barrier or
    synchronization issues to consider, nor any chance a vcpu will see its
    own clock record in a partially updated state.

    I notice the current kvm implementation is the same.

    However, the pvclock_clocksource_read() implementation is
    over-engineered, because it checks for an odd version and uses very
    strong rmb() barriers (which generates either an "lfence" or "lock add
    $0, (%esp)").

    If we're happy to guarantee as an ABI issue that the record will never
    be updated cross-cpu, then we can make the barriers simply barrier() and
    just check for (src->version != dst->version).

    Is that OK with you, or do you want to leave open the possibility of
    doing cross-cpu time updates?


     \ /
      Last update: 2008-08-08 21:55    [W:0.036 / U:114.280 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site