| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] x86: unconditionally mark TSC unstable under
On Wed, 14 Jul 2010, Jeremy Fitzhardinge wrote:
> On 07/14/2010 12:24 PM, Jed Smith wrote:
> > Jeremy, Jan - what do you think? Is this a bad move? I feel like there
> > is a consequence to this that I am unaware of, but it fixes my issue.
> >
>
> Ah, well that's interesting.
>
> There's a couple of comments:
>
> 1. you can't do this with just a compile-time test, since the same
> kernel can also boot native
> 2. nothing in a Xen PV domU environment should be using the tsc
> directly, so this shouldn't have an effect. If something is using
> the tsc we should track it down.
>
> I wonder, however, if you're getting the same result as Jan's suggestion
> of making sched_clock unstable by making the tsc unstable.
>
> In that case, this patch may help:
>
> Subject: [PATCH] xen: disable xen_sched_clock by default
>
> xen_sched_clock only counts unstolen time. In principle this should
> be useful to the Linux scheduler so that it knows how much time a process
> actually consumed. But in practice this doesn't work very well as the
> scheduler expects the sched_clock time to be synchronized between
> cpus. It also uses sched_clock to measure the time a task spends
> sleeping, in which case "unstolen time" isn't meaningful.
>
> So just use plain xen_clocksource_read to return wallclock nanoseconds
> for sched_clock.
>
I think that in this context is worth mentioning that
xen_clocksource_read ends up calling pvclock_get_nsec_offset that calls
native_read_tsc.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home