From: "Jan Beulich" <JBeulich@suse.com>
To: Dario Faggioli <dario.faggioli@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
Joao Martins <joao.m.martins@oracle.com>,
Tim Deegan <tim@xen.org>,
George Dunlap <george.dunlap@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: BUG: NOW() seems to (sometimes) go backwards!
Date: Wed, 08 Jun 2016 04:42:37 -0600 [thread overview]
Message-ID: <575812BD02000078000F2F82@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1465314895.15816.165.camel@citrix.com>
>>> On 07.06.16 at 17:54, <dario.faggioli@citrix.com> 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@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-06-08 10:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 15:54 BUG: NOW() seems to (sometimes) go backwards! Dario Faggioli
2016-06-08 10:42 ` Jan Beulich [this message]
2016-06-08 13:43 ` Dario Faggioli
2016-06-08 14:01 ` Jan Beulich
2016-06-08 20:36 ` Joao Martins
2016-06-09 8:05 ` Jan Beulich
2016-06-09 10:24 ` Joao Martins
2016-06-09 10:43 ` Joao Martins
2016-06-09 11:25 ` Jan Beulich
2016-06-09 11:31 ` Jan Beulich
2016-06-09 10:19 ` George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=575812BD02000078000F2F82@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=joao.m.martins@oracle.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).