linux-kernel - Re: clock_getres() and real resolution

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 11 Feb 2012 08:39:49 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	Dmitry Antipov <dmitry.antipov@...aro.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <john.stultz@...aro.org>,
	linux-kernel@...r.kernel.org, linaro-dev@...ts.linaro.org
Subject: Re: clock_getres() and real resolution

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 ~100000x more accurate hrtimers than it's said,
> and it's a bug. My panda board (with 32K timer enabled) has ~30000x
> less accurate hrtimers than it's said, and it's not a bug. Great.

If I understand you correctly, what you are looking for is a way to
get a promise from the OS regarding a real time deadlines, right?
But that is a different question than the timer unit resolution:

Q: What is the finest timer duration that I may request?
A: One nanosecond (answer by getres).

Q: What kind of real time deadline will my system provide?
A: Nobody knows for sure.

Just because the OS claims timer resolution X does mean that your
application can assume, "okay, I'll just set my periodic task at
duration X and the OS will take care of the rest." The only thing the
user can count on is that the timer expiration will not come _before_
the deadline. The nanosleep man page puts its like this:

   If the interval specified in req is not an exact multiple of the
   granularity underlying clock (see time(7)), then the interval will
   be rounded up to the next multiple.  Furthermore, after the sleep
   completes, there may still be a delay before the CPU becomes free
   to once again execute the calling thread.

I agree that getres does not provide very useful information. Under
Linux, it merely indicates the present of high resolution timer
support.

The practical solution to what you are asking for is overall system
testing tuning, and this is unfortunately manual labor.

Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/