[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.031 / U:0.916 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site