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]
Message-ID: <Pine.LNX.4.64.0708071417200.1817@scrub.home>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ