RE: [Xen-devel] [PATCH] xen: always set the sched clock asunstable

[Jan Beulich]

>>> On 16.04.12 at 19:30, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
>>  From: David Vrabel [mailto:david.vrabel@xxxxxxxxxx]
>> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
>> 
>> On 16/04/12 17:05, Dan Magenheimer wrote:
>> >> From: David Vrabel [mailto:david.vrabel@xxxxxxxxxx]
>> >> Subject: Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
>> >
>> > Nacked-by: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
>> 
>> Fair enough,
>> 
>> > [A stable clock] should be true for Xen 4.0+ (but not for pre-Xen-4.0).
>> 
>> The original customer problem is on a host with Xen 3.4.  What do you
>> recommend for Linux guests running such hosts?
> 
> For pre-Xen-4.0 and an unchanged PV guest, I don't know.  If you can
> back-patch the guest kernel with a workaround such as your patch, great!
> I'm only arguing against the patch getting perpetuated upstream.
>  
>> > 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.
>> 
>> So, should the xen clocksource do:
>> 
>> if Xen 4.0+
>>     clock is stable, use rdtsc only.
>> else
>>     clock is unstable, use existing pvclock implementation.
> 
> Yes, that's what I propose.  To clarify:
> 
> if the guest can and does determine it is running on Xen 4.0+

_and_ TSC reads are emulated (which I don't think they are by
default).

Jan

> 	TSC is guaranteed by Xen to be stable, use clocksource=tsc tsc=reliable
> else
> 	Xen only guarantees that pvclock is stable, use pvclock


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/