From: Ingo Molnar <mingo@elte.hu>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Arjan van de Ven <arjan@infradead.org>
Subject: Re: [PATCH/RFC] msleep() with hrtimers
Date: Mon, 16 Jul 2007 18:10:25 +0200 [thread overview]
Message-ID: <20070716161025.GA1797@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.64.0707161654130.1817@scrub.home>
* Roman Zippel <zippel@linux-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
next prev parent reply other threads:[~2007-07-16 16:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-15 22:42 [PATCH/RFC] msleep() with hrtimers Jonathan Corbet
2007-07-15 23:10 ` Arnd Bergmann
2007-07-16 10:48 ` Ingo Molnar
2007-07-16 11:39 ` Roman Zippel
2007-07-16 11:47 ` Ingo Molnar
2007-07-16 11:54 ` Roman Zippel
2007-07-16 11:57 ` Ingo Molnar
2007-07-16 12:05 ` Roman Zippel
2007-07-16 12:19 ` Ingo Molnar
2007-07-16 13:00 ` Roman Zippel
2007-07-16 14:09 ` Ingo Molnar
2007-07-16 14:32 ` Roman Zippel
2007-07-16 14:42 ` Jonathan Corbet
2007-07-16 15:18 ` Ingo Molnar
2007-07-16 15:43 ` Roman Zippel
2007-07-16 15:57 ` Ray Lee
2007-07-16 16:08 ` Nish Aravamudan
2007-07-17 4:04 ` Nick Piggin
2007-07-18 17:53 ` Nish Aravamudan
2007-07-16 16:10 ` Ingo Molnar [this message]
2007-07-16 16:55 ` Roman Zippel
2007-07-16 17:46 ` Jonathan Corbet
2007-07-20 12:49 ` Roman Zippel
2007-07-16 14:11 ` Roman Zippel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070716161025.GA1797@elte.hu \
--to=mingo@elte.hu \
--cc=arjan@infradead.org \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox