| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
|
To: |
Avi Kivity <avi@xxxxxxxxxx> |
|
Subject: |
RE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation |
|
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
|
Date: |
Thu, 5 Nov 2009 06:52:38 -0800 (PST) |
|
Cc: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>, kurt.hackel@xxxxxxxxxx, Glauber Costa <glommer@xxxxxxxxxx>, the arch/x86 maintainers <x86@xxxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, zach.brown@xxxxxxxxxx, Ingo Molnar <mingo@xxxxxxxxxx>, chris.mason@xxxxxxxxxx |
|
Delivery-date: |
Thu, 05 Nov 2009 06:55:29 -0800 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4AF274E5.5080205@xxxxxxxxxx> |
|
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 |
> From: Avi Kivity [mailto:avi@xxxxxxxxxx]
>
> Within a process, yes. Across processes, not without writable shared
> memory.
>
> That's why I'm trying to understand what the actual
> requirements are.
> Real monotonic, accurate, high resolution, low cost time sources are
> hard to come by.
Hmmm... this has significant implications for the rdtsc
emulation discussion on xen-devel. Since that's not
a Linux question, I'll start another thread on xen-devel
with a shorter cc list.
> > Actually, I think for many/most profiling applications,
> > just knowing a discontinuity occurred between two
> > timestamps is very useful as that one specific measurement
> > can be discarded. If a discontinuity is invisible,
> > one clearly knows that a negative interval is bad,
> > but if an interval is very small or very large,
> > one never knows if it is due to a discontinuity or
> > due to some other reason.
> >
> > This would argue for a syscall/vsyscall that can
> > "return" two values: the "time" and a second
> > "continuity generation" counter.
>
> I doubt it. You should expect discontinuities in user space due to
> being swapped out, scheduled out, migrated to a different
> cpu, or your
> laptop lid being closed. There are no guarantees to a userspace
> application. Even the kernel can expect discontinuities due
> to SMIs.
> So an explicit notification about one type of discontinuity
> adds nothing.
Good point. I'm interested in enterprise apps that have more
control over the machine (and rarely suffer from laptop lid
closures :-) and would intend for all discontinuities visible
to a hypervisor or kernel to increment "AUX", but bare-metal-
kernel-invisible discontinuities such as SMI do throw a wrench
in the works.
Well, all this discussion has convince me that
my original proposals do make sense for enterprise apps to be
virtualization-aware and use rdtsc/p directly for timestamping
needs rather than OS APIs (with the hypervisor deciding
whether or not to emulate rdtsc/p based on the underlying
physical machine and whether or not migration is enabled
or has occurred).
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home