[lkml]   [2009]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [Xen-devel] Re: [PATCH 3/5] x86/pvclock: add vsyscall implementation
    > From: Avi Kivity []
    > 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).

     \ /
      Last update: 2009-11-05 15:57    [W:0.022 / U:0.796 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site