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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 16 Jul 2007 18:10:25 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH/RFC] msleep() with hrtimers

* Roman Zippel <zippel@...ux-m68k.org> wrote:

> I know that Ingo considers everything HZ related evil, [...]

no, you are misrepresenting me, i dont consider everything HZ related 
evil - where did you get that from?

I explained it numerous times (remember the 'timeout' vs. 'timer event' 
discussion?) that i consider timer granularity important to scalability. 
Basically, in every case where we know with great certainty that a 
time-out will _not_ occur (where the time-out is in essence just an 
exception handling mechanism), using struct timer_list is the best 
solution. Furthermore, in cases where we know that the "granularity" of 
a timer event is coarse, we can 'cluster' related timer events together. 
(Arjan's timeout-rounding API additions do that.)

msleep() API is neither, and it's a perfect example for conversion to 
hrtimers. It is exactly the type of timer API we intended hrtimers for.

what i consider harmful on the other hand are all the HZ assumptions 
embedded into various pieces of code. The most harmful ones are design 
details that depend on HZ and kernel-internal API details that depends 
on HZ. Yes, NTP was such an example, and it was hard to fix, and you 
didnt help much with that. (perhaps that is one source of this 
increasingly testy exchange ;-) In any case we are slowly and surely 
eradicating them. (we long ago eradicated all externally visible HZ 
dependencies via the introduction of USER_HZ)

	Ingo
-
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/