Re: [Xen-devel] BUG: NOW() seems to (sometimes) go backwards!

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.06.16 at 17:54, <dario.faggioli@xxxxxxxxxx> wrote:
> So, it looks to me that the TSC is actually ok, and it could be the
> local_tsc_stamp and scale_delta() magic done in get_s_time_fixed()
> (which, AFAICUI, is there to convert cycles to time) that does not
> guarantee the result to be monotonic, even if the input is... Thoughts?

Indeed this smells like an issue in the scaling. However, the scaling
values vary only when !CONSTANT_TSC. Can you check that this
flag is actually set on that system? (I hope you're not running a
strange Dom0 setup with FREQCTL_dom0_kernel in effect.) And
at the same time that it's time_calibration_tsc_rendezvous() that
is in use?

Yet when the scaling values get set only once at boot, monotonic
(cross-CPU) TSC means monotonic (cross-CPU) returns from NOW().

In any event - could you try to exclude C- and P-state effects? Of
course that makes sense only if you can reasonably repro the
problem situation (and hence can tell from its absence over a certain
period of time that whatever change was done did have some
positive effect).

How big of system are we talking about? I'm asking to assess the
overhead of adding some cross-CPU checks to get_s_time_fixed()
(in a debugging patch), logging relevant values if non-monotonic
output gets detected. (On too big a system, the overhead here
might end up masking the problem.)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel