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

From: Jan Beulich
Date: Tue Apr 17 2012 - 03:27:20 EST

>>> On 16.04.12 at 19:22, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> In upstream (and recent pv-ops) kernels, is there any need for there
> to be a difference between HVM and PV in the clocksource chosen? The

Yes, because RDTSC interception for PV guests is slow (using #GP
and requiring instruction decode).

> pvclock algorithm was necessary for PV when non-TSC hardware clocks
> were privileged and the only non-privileged hardware clock (TSC)
> was badly broken in hardware and for migration/save/restore.
> With TSC now working and stable, and now that we are making changes
> in the upstream kernel that work for both PV and HVM, is it
> time to drop pvclock (at least as the default for PV)?
> Certainly if an old (non-pv-ops) kernel is broken, something like
> David's patch might be an acceptable workaround. I'm just arguing
> against perpetuating pvclock-as-the-only-xen-clock upstream.

Afaict, the only uniformly reliable clocksource for PV guests is the
virtual one which pvclock builds upon. Raw TSC is definitely not an
option on NUMA systems (and PV guests aren't aware of the
NUMAness of the underlying system).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at