From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Lee Revell <rlrevell@joe-job.com>,
dean gaudet <dean-list-linux-kernel@arctic.org>,
Chris Wedgwood <cw@f00f.org>, Andrew Morton <akpm@osdl.org>,
"Brown, Len" <len.brown@intel.com>,
dtor_core@ameritech.net, vojtech@suse.cz,
david.lang@digitalinsight.com, davidsen@tmr.com,
kernel@kolivas.org, linux-kernel@vger.kernel.org,
mbligh@mbligh.org, diegocg@gmail.com, azarah@nosferatu.za.org,
christoph@lameter.com
Subject: Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt
Date: Thu, 14 Jul 2005 10:38:43 +0200 [thread overview]
Message-ID: <20050714083843.GA4851@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.58.0507131847000.17536@g5.osdl.org>
* Linus Torvalds <torvalds@osdl.org> wrote:
> I suspect that it is impractical to reprogram the PIT on a very fine
> granularity.
yes - reprogramming the PIT can take up to 10 usecs even on recent PCs.
(in fact the cost is pretty much system-independent due to PIO.) On
modern, PIT-less timesources (e.g. HPET) it can be faster.
> Btw, if somebody really gets excited about all this, let me say (once
> again) what I think might be an acceptable situation.
>
> First off, I'm _not_ a believer in "sub-HZ ticks". Quite the reverse.
> I think we should have HZ be some high value, but we would _slow_down_
> the tick when not needed, and count by 2's, 3's or even 10's when
> there's not a lot going on.
i think that would be an acceptable solution for high-precision timers,
as long as two other problems are solved too:
- there are real-time applications (robotic environments: fast rotating
tools, media and mobile/phone applications, etc.) that want 10
usecs precision. If such users increased HZ to 100,000 or even
1000,000, the current timer implementation would start to creek: e.g.
jiffies on 32-bit systems would wrap around in 11 hours or 1.1 hours.
(To solve this cleanly, pretty much the only solution seems to be to
increase the timeout to a 64 bit value. A non-issue for 64-bit
systems, that's why i think we could eventually look at this
possibility, once all the other problems are hashed out.)
- at very high HZ values the clustering of e.g. network timers is lost,
creating an artificially high number of timer interrupts. So likely
we'd still need some way to 'blur' timeouts and to round e.g. network
timers to the next 1 msec or 500 usecs boundary, to cluster up timers
for bulk processing. But in any case, such a solution does not sound
nearly as messy as the sub-jiffies method.
if the 'high precision' uses are not addressed [*] i fear the whole HRT
game starts again: embedded folks trying to standardize on Linux for
everything [**] will want HRT timers and will do addons and sub-jiffy
approaches [***], and will push for inclusion. I think we could as well
solve this whole problem area by making ridiculously high HZ values
practical too!
Ingo
[*] there's also a third problem: timer prioritization. It's not
necessarily a problem the upstream kernel should care about, but
it's a problem for things that try to offer hard-real-time, like
PREEMPT_RT: HRT timers need to be prioritizable. If e.g. the system
is soaked handling network timers, it should still be possible for
that single mega-important HRT timer to run and wake up the
mega-high-priority RT task that will preempt all network activity
within 10 usecs worst-case. The sub-jiffies approach does this
prioritization in a natural way, because there HRT timers are
separate, so the prioritization of them is easy. With the grand
unified 'big HZ' scheme the HRT folks would have to implement a
mechanism to split off highprio timers from the stream of normal
timers. ]
[**] having high precision is also a perception and uniformity of
platform issue: most embedded developers will find 500 usecs
precision good enough for most uses, but it does not 'sound' good
enough, and there's no easy way out either. So _if_ there's the
occasional need for higher precision they'll have no easy solution
for Linux, and this prevents them from standardizing on Linux for
_everything_.
[***]
a side-thought about sub-jiffies: the biggest conceptual problem
the sub-jiffy method has is the sorting needed when timers move from
the jiffy bucket into the HRT list which doesnt scale - but this is
really a HRT-timers-internal problem. It could be further improved
by e.g. dividing the last jiffy up into say 10 usec buckets - with a
1msec jiffy clock that's 100 buckets, and having a bitmap to see
which bucket is active. Then the 'get the next timer' act becomes a
matter of searching the bitmap for the next bit set - at pretty much
constant overhead. Even a 1 usec precision would mean only 1000
buckets for the last jiffy, with 1000 bits (128 bytes) to search,
still quite ok. But, in any case, it would be nice to avoid the
"conceptual dualness" of the HRT patch.
next prev parent reply other threads:[~2005-07-14 8:39 UTC|newest]
Thread overview: 238+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200506231828.j5NISlCe020350@hera.kernel.org>
2005-07-08 21:49 ` [PATCH] i386: Selectable Frequency of the Timer Interrupt Chris Wedgwood
2005-07-08 21:59 ` Andrew Morton
2005-07-08 22:05 ` Chris Wedgwood
2005-07-08 22:08 ` Linus Torvalds
2005-07-10 10:45 ` Denis Vlasenko
2005-07-08 22:22 ` Lee Revell
2005-07-08 22:33 ` Andrew Morton
2005-07-08 22:59 ` Martin J. Bligh
2005-07-08 23:03 ` Chris Wedgwood
2005-07-08 23:14 ` Martin J. Bligh
2005-07-08 23:29 ` David S. Miller
2005-07-08 23:40 ` Lee Revell
2005-07-09 17:08 ` Martin Schlemmer
2005-07-09 18:16 ` Lee Revell
2005-07-09 18:31 ` Arjan van de Ven
2005-07-09 18:33 ` Chris Wedgwood
2005-07-09 18:36 ` Lee Revell
2005-07-09 19:12 ` Andrew Morton
2005-07-09 19:16 ` Lee Revell
2005-07-09 20:30 ` randy_dunlap
2005-07-09 21:25 ` Lee Revell
2005-07-09 23:30 ` Randy Dunlap
2005-07-11 18:35 ` Martin J. Bligh
2005-07-11 13:23 ` Alan Cox
2005-07-11 14:05 ` Theodore Ts'o
2005-07-11 14:08 ` Arjan van de Ven
2005-07-11 15:18 ` Alan Cox
2005-07-12 2:13 ` Eric St-Laurent
2005-07-11 16:02 ` Chris Wedgwood
2005-07-15 12:17 ` Pavel Machek
2005-07-13 15:59 ` Bill Davidsen
2005-07-13 16:47 ` Lee Revell
2005-07-10 0:44 ` pmarques
2005-07-09 18:39 ` Diego Calleja
2005-07-09 18:41 ` Lee Revell
2005-07-09 18:49 ` Lee Revell
2005-07-09 18:50 ` Chris Wedgwood
2005-07-11 18:38 ` Martin J. Bligh
2005-07-11 20:25 ` Lee Revell
2005-07-11 20:39 ` Chris Friesen
2005-07-12 0:30 ` Lee Revell
2005-07-12 4:07 ` Martin J. Bligh
2005-07-12 4:13 ` Lee Revell
2005-07-12 4:30 ` Martin J. Bligh
2005-07-12 14:21 ` Lee Revell
2005-07-12 14:24 ` Lee Revell
2005-07-12 14:56 ` Martin J. Bligh
2005-07-12 15:00 ` Lee Revell
2005-07-12 15:08 ` Martin J. Bligh
2005-07-12 15:10 ` Lee Revell
2005-07-12 15:22 ` Martin J. Bligh
2005-07-12 19:30 ` Lee Revell
2005-07-12 20:58 ` Lee Revell
2005-07-12 22:22 ` Martin J. Bligh
2005-07-13 5:37 ` Lee Revell
2005-07-13 10:38 ` Jan Engelhardt
2005-07-13 18:42 ` High irq load (Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt) Linus Torvalds
2005-07-14 14:25 ` Peter Osterlund
2005-07-18 5:53 ` Herbert Poetzl
2005-07-12 0:38 ` [PATCH] i386: Selectable Frequency of the Timer Interrupt George Anzinger
2005-07-12 12:10 ` Vojtech Pavlik
2005-07-12 12:39 ` Con Kolivas
2005-07-12 12:52 ` Con Kolivas
2005-07-12 15:57 ` George Anzinger
2005-07-12 16:27 ` Vojtech Pavlik
2005-07-13 16:26 ` Bill Davidsen
2005-07-13 16:46 ` Lee Revell
2005-07-13 17:24 ` David Lang
2005-07-13 18:42 ` Vojtech Pavlik
2005-07-13 19:10 ` Linus Torvalds
2005-07-13 19:13 ` Lee Revell
2005-07-13 19:32 ` Dmitry Torokhov
2005-07-13 19:33 ` Martin J. Bligh
2005-07-13 20:02 ` Fernando Lopez-Lezcano
2005-07-13 20:17 ` Lee Revell
2005-07-13 20:24 ` Lee Revell
2005-07-13 20:48 ` Andrew Morton
2005-07-13 21:16 ` Chris Wedgwood
2005-07-13 21:24 ` Lee Revell
2005-07-13 21:35 ` Martin J. Bligh
2005-07-13 21:37 ` Chris Friesen
2005-07-13 21:56 ` Chris Wedgwood
2005-07-13 23:07 ` George Anzinger
2005-07-13 21:29 ` Martin J. Bligh
2005-07-13 21:30 ` Lee Revell
2005-07-13 23:41 ` dean gaudet
2005-07-14 0:07 ` Petr Vandrovec
2005-07-14 9:24 ` Jan Engelhardt
2005-07-14 14:20 ` Lee Revell
2005-07-14 18:05 ` Jan Engelhardt
2005-07-14 18:20 ` Linus Torvalds
2005-07-14 0:51 ` Chris Wedgwood
2005-07-14 1:13 ` dean gaudet
2005-07-14 1:33 ` Lee Revell
2005-07-14 1:54 ` Linus Torvalds
2005-07-14 7:42 ` Arjan van de Ven
2005-07-14 12:13 ` Vojtech Pavlik
2005-07-14 16:37 ` Linus Torvalds
2005-07-14 17:02 ` Arjan van de Ven
2005-07-14 17:21 ` Linus Torvalds
2005-07-14 19:09 ` Russell King
2005-07-14 20:06 ` Linus Torvalds
2005-07-14 20:30 ` Russell King
2005-07-15 8:15 ` Gerd Knorr
2005-07-14 20:38 ` Johannes Stezenbach
2005-07-14 17:42 ` Al Boldi
2005-07-14 19:42 ` john stultz
2005-07-14 20:13 ` Linus Torvalds
2005-07-14 20:41 ` Christoph Lameter
2005-07-14 23:03 ` Chris Wedgwood
2005-07-14 21:54 ` john stultz
2005-07-14 22:43 ` Alan Cox
2005-07-14 23:19 ` Linus Torvalds
2005-07-15 12:33 ` Alan Cox
2005-07-14 17:10 ` Chris Friesen
2005-07-14 17:24 ` Linus Torvalds
2005-07-14 19:18 ` john stultz
2005-07-14 22:37 ` Alan Cox
2005-07-14 23:13 ` Linus Torvalds
2005-07-14 23:32 ` Linus Torvalds
2005-07-15 1:17 ` Eric St-Laurent
2005-07-14 23:17 ` Lee Revell
2005-07-14 23:25 ` Linus Torvalds
2005-07-14 23:41 ` Lee Revell
2005-07-14 23:49 ` Linus Torvalds
2005-07-14 23:53 ` Lee Revell
2005-07-15 12:42 ` Bill Davidsen
2005-07-14 23:57 ` Lee Revell
2005-07-15 2:30 ` Fernando Lopez-Lezcano
2005-07-15 12:46 ` Bill Davidsen
2005-07-15 16:46 ` Fernando Lopez-Lezcano
2005-07-30 5:49 ` [GIT PATCH] ACPI patches for 2.6.13 Len Brown
2005-07-30 9:58 ` [ACPI] " Pavel Machek
2005-08-03 23:16 ` [GIT PATCH] ACPI patches for 2.6.13-rc5 Len Brown
2005-08-04 17:11 ` [GIT PATCH] ACPI patches for 2.6.13-rc5+ Len Brown
2005-08-15 20:35 ` [GIT PATCH] ACPI patch for 2.6.13-rc6 Len Brown
2005-07-14 23:50 ` [PATCH] i386: Selectable Frequency of the Timer Interrupt Lee Revell
2005-07-15 4:08 ` Con Kolivas
2005-07-15 4:17 ` Lee Revell
2005-07-15 4:54 ` Zwane Mwaikambo
2005-07-15 16:59 ` Lee Revell
2005-07-15 14:51 ` kernel
2005-07-14 18:00 ` Andrew Morton
2005-07-14 8:38 ` Ingo Molnar [this message]
2005-07-14 14:55 ` Lee Revell
2005-07-14 15:02 ` Christoph Lameter
2005-07-14 15:25 ` Lee Revell
2005-07-15 11:38 ` [OT] high precision hardware (was Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt) Paul Jakma
2005-07-15 15:57 ` Christoph Lameter
2005-07-15 16:13 ` Lee Revell
2005-07-14 2:08 ` [PATCH] i386: Selectable Frequency of the Timer Interrupt Lee Revell
2005-07-14 9:56 ` Maciej W. Rozycki
2005-07-15 0:04 ` Jesper Juhl
2005-07-15 0:15 ` Lee Revell
2005-07-15 0:17 ` Jesper Juhl
2005-07-15 0:42 ` Linus Torvalds
2005-07-15 8:41 ` Russell King
2005-07-15 0:24 ` Linus Torvalds
2005-07-15 1:40 ` Jesper Juhl
2005-07-15 2:00 ` Eric St-Laurent
2005-07-15 19:58 ` Stephen Pollei
2005-07-16 5:16 ` Eric St-Laurent
2005-07-15 2:07 ` Bill Davidsen
2005-07-15 9:36 ` Matthias Urlichs
2005-07-15 3:46 ` Jesper Juhl
2005-07-15 5:04 ` Linus Torvalds
2005-07-15 13:12 ` Jesper Juhl
2005-07-17 2:13 ` Jesper Juhl
2005-07-17 2:35 ` Lee Revell
2005-07-17 2:35 ` Nish Aravamudan
2005-07-17 3:55 ` Lee Revell
2005-07-23 23:40 ` randy_dunlap
2005-07-25 13:26 ` Vojtech Pavlik
2005-07-23 23:48 ` randy_dunlap
2005-07-23 23:52 ` Jesper Juhl
2005-07-24 12:58 ` Bill Davidsen
2005-07-15 8:44 ` Russell King
2005-07-15 15:41 ` Pavel Machek
2005-07-13 20:02 ` Diego Calleja
2005-07-13 19:35 ` Benjamin LaHaise
2005-07-13 19:41 ` Vojtech Pavlik
2005-07-13 19:53 ` Benjamin LaHaise
2005-07-14 10:04 ` Maciej W. Rozycki
2005-07-13 19:52 ` George Anzinger
2005-07-13 23:54 ` Con Kolivas
2005-07-14 0:43 ` George Anzinger
2005-07-14 10:25 ` Krzysztof Halasa
2005-07-14 12:19 ` Vojtech Pavlik
2005-07-14 21:19 ` Krzysztof Halasa
2005-07-15 1:19 ` Bill Davidsen
2005-07-12 13:30 ` Vojtech Pavlik
2005-07-12 14:05 ` Jan Engelhardt
2005-07-12 16:07 ` Vojtech Pavlik
2005-07-12 15:26 ` [PATCH] " Martin J. Bligh
2005-07-12 17:50 ` john stultz
2005-07-12 22:30 ` Nishanth Aravamudan
2005-07-12 17:56 ` john stultz
2005-07-12 0:45 ` Lee Revell
2005-07-11 13:18 ` Alan Cox
[not found] <F7DC2337C7631D4386A2DF6E8FB22B300410F46A@hdsmsx401.amr.corp.intel.com.suse.lists.linux.kernel>
2005-07-15 17:02 ` Andi Kleen
2005-07-15 17:23 ` Venkatesh Pallipadi
2005-07-15 17:54 ` Maciej W. Rozycki
2005-07-15 17:58 ` Andi Kleen
2005-07-18 10:47 ` Maciej W. Rozycki
2005-07-15 18:01 ` Venkatesh Pallipadi
2005-07-18 11:17 ` Maciej W. Rozycki
2005-07-15 17:57 ` Andi Kleen
2005-07-15 18:09 ` Venkatesh Pallipadi
2005-07-15 16:33 Brown, Len
2005-07-15 16:54 ` Chris Wedgwood
-- strict thread matches above, loose matches on Subject: below --
2005-07-14 21:35 Brown, Len
2005-07-15 9:37 ` Maciej W. Rozycki
2005-05-16 19:45 christoph
2005-05-16 20:51 ` Lee Revell
2005-05-17 0:55 ` christoph
2005-05-17 23:25 ` Lee Revell
2005-05-17 23:48 ` Nish Aravamudan
2005-05-18 0:03 ` Valdis.Kletnieks
2005-05-18 0:08 ` Lee Revell
2005-05-16 22:09 ` Andrew Morton
2005-05-17 2:38 ` Christoph Lameter
2005-05-17 2:46 ` randy_dunlap
2005-05-17 2:55 ` Christoph Lameter
2005-05-17 3:01 ` randy_dunlap
2005-05-17 3:37 ` Linus Torvalds
2005-05-17 3:40 ` Andi Kleen
2005-05-17 10:51 ` Paulo Marques
2005-05-17 13:19 ` Andi Kleen
2005-05-17 5:31 ` Christoph Lameter
2005-05-17 13:44 ` Joe Korty
2005-05-17 13:58 ` Andi Kleen
2005-05-17 15:43 ` Christoph Lameter
2005-05-18 18:50 ` Pavel Machek
2005-05-18 19:03 ` Lee Revell
2005-05-18 20:41 ` Tony Lindgren
2005-05-18 19:25 ` Linus Torvalds
2005-05-18 20:46 ` Tony Lindgren
2005-05-17 3:01 ` Coywolf Qi Hunt
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=20050714083843.GA4851@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=azarah@nosferatu.za.org \
--cc=christoph@lameter.com \
--cc=cw@f00f.org \
--cc=david.lang@digitalinsight.com \
--cc=davidsen@tmr.com \
--cc=dean-list-linux-kernel@arctic.org \
--cc=diegocg@gmail.com \
--cc=dtor_core@ameritech.net \
--cc=kernel@kolivas.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@mbligh.org \
--cc=rlrevell@joe-job.com \
--cc=torvalds@osdl.org \
--cc=vojtech@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).