WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [PATCH?] monotonically increasing Xen system time

To: "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH?] monotonically increasing Xen system time
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 28 Jul 2008 11:04:21 -0600
Cc:
Delivery-date: Mon, 28 Jul 2008 10:05:44 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acjw0/jRCp8bdZzjRjSmW5zeDsAKCQ==
(This is probably post-3.3, but feedback would be appreciated
as I would hope it could go into 3.3.1 if it doesn't make 3.3.)

I've finally surrendered to the fact that intra-CPU stime skew
can't be reduced down to the point where it can be ignored,
at least on non-tsc-invariant boxes.  It always seems to
max out at least at several microseconds, and in some cases
in tens of microseconds.  This is probably a result of
crystal oscillation drift, and perhaps the "beating" of
the platform timer crystal vs the tsc crystal.

So the attached patch adds a get_s_time_mono() call that
always returns a monotonically INcreasing (not just
non-decreasing) stime.  A stime_minstep is computed that
guarantees that mono_stime can't increase faster than
stime, even if all processors are pounding on stime
in a loop.  The result is the resolution for mono_stime.
(On my dual-core box, it's 24ns... your mileage may vary.)

I want to use this in hvm_get_guest_time() (and thus for
softtsc) but it may also be appropriate for at least some
of the many uses of NOW() in Xen.  If so, it might make
sense that this should be the default get_s_time() and the
current get_s_time() should be renamed get_local_s_time().
In any case, there are most likely other uses for it
in Xen so I didn't want to build it just into
hvm_get_guest_time().

(Note that init_xen_time() was moved down in __start_xen()
because num_online_cpus() gave the wrong answer at its
current position.)

Signed-off-by: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>

===================================
Thanks... for the memory
I really could use more / My throughput's on the floor
The balloon is flat / My swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to the late great Bob Hope)

Attachment: stimemono.patch
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>