linux-kernel - Re: [PATCH/RFC] msleep() with hrtimers

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Pine.LNX.4.64.0707161325040.1818@scrub.home>
Date:	Mon, 16 Jul 2007 13:39:48 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Jonathan Corbet <corbet@....net>
cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH/RFC] msleep() with hrtimers

Hi,

On Sun, 15 Jul 2007, Jonathan Corbet wrote:

> Here's another approach: a reimplementation of msleep() and
> msleep_interruptible() using hrtimers.  On a system without real
> hrtimers this code will at least drop down to single-jiffy delays much
> of the time (though not deterministically so).  On my x86_64 system with
> Thomas's hrtimer/dyntick patch applied, msleep(1) gives almost exactly
> what was asked for.

One possible problem here is that setting up that timer can be 
considerably more expensive, for a relative timer you have to read the 
current time, which can be quite expensive (e.g. your machine now uses the 
PIT timer, because TSC was deemed unstable).
One question here would be, is it really a problem to sleep a little more?
Another possibility would be to add another sleep function, which uses 
hrtimer and could also take ktime argument.

bye, Roman
-
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/