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

From: Dan Magenheimer
Date: Mon Apr 16 2012 - 13:31:03 EST


> 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+
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/