This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] RE: [PATCH/RFC] report hardware tsc frequency even for emula

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: [Xen-devel] RE: [PATCH/RFC] report hardware tsc frequency even for emulated tsc
From: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 30 Nov 2009 12:51:40 -0800 (PST)
Cc: "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 30 Nov 2009 12:52:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B141B41.50702@xxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Jeremy --

Thanks for the comments.

> > This patch changes the reported hz rate to the
> > hz rate of the initial machine on which the guest
> > is booted and retains that reported hz rate across
> > save/restore/migration.
> The pvclock algorithm relies on knowing what rate the tsc 
> advances at. 
> If you return  the "real" tsc speed in the clock info, won't 
> that break?

As long as the "illusion" provided via both rdtsc and
pvclock are consistent, it works.
> > Jeremy has pointed out that reporting 1000.0 MHz is
> > useful because it shows that TSC is being emulated.
> > However, with the new tsc_mode default where
> > a guest may start with native TSC and switch to
> > emulated TSC after migration, users are likely to
> > get even more confused.
> I don't see how the original CPU speed is any more relevant than the
> emulated speed, which is at least constant.
> The CPU speed is fairly
> pointless info given that it has no bearing on how fast the CPU is
> running from moment to moment, even ignoring migration.

It's not more relevant, it's just less shocking.  The vast
majority of users don't know (or care) that the MHz rate
reported for the CPU is derived from the TSC rate.  They
will just think, with a 1GHz reported rate in their guest, 
that Xen has done something horribly wrong to slow down
their processor.

Our esteemed large competitor appears to report something
like the hz rate of the initial machine, even though they
always do "emulation".  So if all other things are equal,
I'd be inclined to follow suit.

> (On native "cpu
> MHz" updates on the fly as the CPU speed changes, but I don't 
> think your proposal will allow that.)

I wasn't aware of that.  My proposal could allow for that but
the specific proposed patch doesn't.  It could only be
done I think if one didn't care about the TSC hz rate
given to apps... if that's true, just turn off TSC emulation.

> >   And "xm debug-key s"
> > reveals not only whether TSC is being emulated but
> > also the frequency so is more descriptive anyway.
> It is not available to non-privileged users.

Good point.  OTOH, if one cared to do something to change
tsc emulation, one would need to be privileged to relaunch
the domain.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>