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


RE: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ti

To: "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 25 Feb 2008 09:42:02 -0700
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Deepak Patel <deepak.patel@xxxxxxxxxx>
Delivery-date: Mon, 25 Feb 2008 08:42:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47BB410F.8000904@xxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ach3zVW8UAjxFwILQOuu3dYGwqhWeA==
Hi Dave --

I've looked into RHEL5-64 a bit more and would appreciate
any thoughts you might have:

> >So, some open questions:
> >[2] In RHEL5, I *think* it is the WALL source that we care about?
> >
> >
> I'll have to check on this too.

On second look, I may be wrong.  The GTOD clock seems to be
the one associated with vxtime.mode and vxtime.mode is used in
linux- to
determine if a tick is lost or not.  Is this the code that we
want timer_mode=2 to influence?

> >[1] Is notsc necessary for proper ticks for RHEL4-32/RHEL5-64?
> >    (I *think* not as it has never come up in any email.)
> >
> >
> I have not investigated this yet.

Well for RHEL5-64, looking at linux-,
it appears whether notsc is required or not depends in part on the
underlying virtual AND physical system.

notsc definitely is involved in the selection of GTOD time
but notsc can get set not only by kernel command line parameter
but also by the result of unsynchronized_tsc():

if (apic_is_clustered_box) notsc=1
if (box_is_Intel) {
        /* C3 delay is worst case HW latency to enter/exit C3 state */
        if (C3 delay < 1000) notsc=1
else { /* e.g. AMD */
        if (num_present_cpus() > 1) notsc=1

I'm not sure what constitutes a clustered HVM guest or how that
C3 state latency is determined under Xen, but its clear that the
clocksource can be influenced not only by what clock hardware is
present and command-line parameters but also by the physical CPU
and number of guest vcpus.



Xen-devel mailing list

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