linux-kernel - Re: [PATCH] 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 7 Aug 2007 14:45:12 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	akpm@...ux-foundation.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] msleep() with hrtimers

Hi,

On Mon, 6 Aug 2007, Arjan van de Ven wrote:

> So, let me ask a direct question: What do you think is specifically
> wrong about changing the msleep() implementation as is done here? The
> behavior is clearly an improvement, so what is your objection on the
> flipside?

Again, we have two different timer APIs for a reason - as long as you 
ignore this, we won't get much further...
As long as resolution is not an issue, simple timer are generally often 
the better choice as they are cheaper. By extension it also makes sense to 
offer a sleep based on simple timer.
hrtimer allows for finer resolution, so it makes more sense to offer a 
hrtimer based sleep which is not limited to milliseconds, once we have 
this sleep, you'll also get the better behaviour you're asking for, which 
removes the urgent need having to "fix" msleep.

Contrary to what you think I don't hate hrtimer, they're quite useful, but 
they have their use cases as simple timer have. What I want is that people 
_think_ before start using them, as in general hrtimer come with a higher 
base cost, so one should _think_ before thoughtlessly using them only 
because they're the cool new thing. I don't care much about drivers, but 
in generic code (which msleep is part of) I'm going to look closer and 
I'll continue to ask, whether it really needs to use hrtimer.
In this case I simply see no reason to force hrtimer on msleep, if users
can as well use nanosleep to get the same behaviour.

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/