[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] xen: always set the sched clock as unstable
>>> 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.
>> 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
> TSC is guaranteed by Xen to be stable, use clocksource=tsc tsc=reliable
> Xen only guarantees that pvclock is stable, use pvclock
Xen-devel mailing list