On Fri, Mar 10, 2006 at 06:20:10PM -0500, Jed Davis wrote:
> I notice, in xen/clock.d:get_time_values_from_xen(), that we're using
> __insn_barrier(), which is just a directive to the compiler, where
> Linux is using (and my minimal understanding of the architecture would
> suggest) an lfence instruction to prevent the CPU from reordering the
> loads and breaking the concurrency protocol.
> 
> I think it's possible that this could be the cause of some of the
> hard-to-reproduce problems I was seeing -- if the 64-bit system_time
> counter could be caught in the middle of an update when the lower word
> (uh, "dword") is rolling over, that would move the apparent time by
> about 4.3s -- and the strange deltas cc_microset had been reporting
> (this was before I replaced it) were usually in the 4.3s-5.3s range,
> which makes sense because cc_microset is called about once a second.
> 
> Thoughts?

Yes, this can be an issue. I've run in such issues in other parts of the kernel
already.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--