On Thu, Feb 09, 2012 at 11:32:16AM -0800, Dmitry Antipov wrote:
On 02/09/2012 10:40 AM, Richard Cochran wrote:
I thought this list was about Linux kernel development, but now it
seems to be about Sun's old bugs.
This Sun (probably) has ~10x more accurate hrtimers than it's said,
and
On 02/09/2012 02:12 AM, Thomas Gleixner wrote:
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
On Wed, Feb 08, 2012 at 08:31:03AM -0800, 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()
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
On 02/09/2012 10:40 AM, Richard Cochran wrote:
I thought this list was about Linux kernel development, but now it
seems to be about Sun's old bugs.
This Sun (probably) has ~10x more accurate hrtimers than it's said,
and it's a bug. My panda board (with 32K timer enabled) has ~3x
less
On Thu, Feb 09, 2012 at 01:25:33AM -0800, Dmitry Antipov wrote:
Old Sun Fire 880, SunOS 5.10 Generic_139555-08.
100ns precision with 10ms finest timer unit???
I thought this list was about Linux kernel development, but now it
seems to be about Sun's old bugs.
Richard
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)
