Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.04.12 at 18:05, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>>  From: David Vrabel [mailto:david.vrabel@xxxxxxxxxx]
>> On 16/04/12 12:32, Jan Beulich wrote:
>> >>>> On 13.04.12 at 20:20, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
>> >> --- a/arch/x86/xen/time.c
>> >> +++ b/arch/x86/xen/time.c
>> >> @@ -473,6 +473,7 @@ static void __init xen_time_init(void)
>> >>   do_settimeofday(&tp);
>> >>
>> >>   setup_force_cpu_cap(X86_FEATURE_TSC);
>> >> + sched_clock_stable = 0;
>> >
>> > This, unfortunately, is not sufficient afaict: If a CPU gets brought up
>> > post-boot, the variable may need to be cleared again. Instead you
>> > ought to call mark_tsc_unstable().
>> 
>> Yeah, mark_tsc_unstable() is the right thing to do.
> 
> NACK!
> 
> No, no, no.  The exact opposite is true.  Like VMware, TSC is
> stable.  The issue is that Linux trusts other clock hardware more
> completely than TSC so whenever there is a problem with another
> clocksource, Linux blames TSC and marks TSC unstable.  But TSC
> on Xen 4.0+ is innocent.  In fact, TSC is a better clocksource
> choice than clocksource=xen (aka pvclock) because pvclock
> indirectly depends on TSC.
> 
> For upstream kernels, the answer is to set clocksource=tsc
> and tsc=reliable, like VMware enforces. See:
> 
> https://lists.ubuntu.com/archives/kernel-team/2008-October/004283.html 
> 
> In fact, it might be wise for a Xen-savvy kernel to check to see
> if it is running on Xen-4.0+ and, if so, force clocksource=tsc
> and tsc=reliable.

Are you possibly mixing up PV and HVM cases? sched_clock_stable
getting set _is_ a problem in PV kernels - we had bug reports long
ago when this first appeared in arch/x86/kernel/cpu/intel.c. I'm
suspecting this because there's not supposed to be (and in non-
pv-ops there is no; in pv-ops I assume it simply has no effect)
clocksource=tsc in PV kernels.

Jan


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