Messages in this thread | | | Date | Fri, 08 Aug 2008 12:51:54 -0700 | From | Jeremy Fitzhardinge <> | Subject | Use 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?
J
| |