[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> 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

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.