[lkml]   [2012]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: clock_getres() and real resolution
    On Wed, 8 Feb 2012, Dmitry Antipov wrote:

    > IIUC, an idea behind clock_getres() is to give a hint about the resolution of
    > specified clock. This hint may be used by an application programmer to check
    > whether
    > this clock is suitable for a some purpose. So why clock_getres() always
    > returns
    > something like {0, 1} (if hrtimers are enabled) regardless of the underlying
    > platform's
    > real numbers?
    > For example, OMAP4's real resolution of CLOCK_REALTIME is 30.5us for 32K timer
    > and 26ns
    > for MPU timer. Such a difference definitely makes sense - but
    > clock_getres(CLOCK_REALTIME,..)
    > always returns {0, KTIME_HIGH_RES}. Since this behavior causes a confusion
    > like
    >, I'm
    > considering
    > this as a stupid misfeature.

    We had this discussion before. The point is that the accuracy of the
    internal kernel timer handling is 1nsec in case of high resolution
    timers. The fact that the underlying clock event device has a coarser
    resolution does not change that.

    It would be possible to return the real resolution of the clock event
    device, but we have systems, where the clockevent device is
    dynamically changing. So which resolution do we expose to an
    application? The one of the current active device or some magic number
    of a device which might not even be initialized? That's more confusing
    than telling user space that high resolution timers are active and the
    kernel is trying to achieve the 1ns accuracy.



     \ /
      Last update: 2012-02-09 11:15    [W:0.020 / U:101.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site