From: Ingo Molnar <mingo@elte.hu>
To: George Anzinger <george@mvista.com>
Cc: Roman Zippel <zippel@linux-m68k.org>,
tglx@linutronix.de, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@osdl.org>,
johnstul@us.ibm.com, paulmck@us.ibm.com,
Christoph Hellwig <hch@infradead.org>,
oleg@tv-sign.ru, tim.bird@am.sony.com
Subject: Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5
Date: Tue, 4 Oct 2005 07:51:11 +0200 [thread overview]
Message-ID: <20051004055111.GA20208@elte.hu> (raw)
In-Reply-To: <4341E206.3090204@mvista.com>
* George Anzinger <george@mvista.com> wrote:
> > yeah, and that's an assumption that simplifies things on SMP
> > significantly. PIT on SMP systems for HRT is so gross that it's not
> > funny. If anyone wants to revive that notion, please do a separate
> > patch and make the case convincing enough ...
>
> Lets not talk about PIT, but, a lot of SMP platforms do NOT have per
> cpu timers. For those, it would seem having per cpu lists to handle
> the timer is not really reasonable.
frankly, such systems are rare, and are an afterthought at most. Think
about it: 8 CPUs and only one hres timer source? It cannot work nor
scale well.
i agree that they might eventually be handled (although i think we
shouldnt bother, all sane SMP designs have per-CPU timers), but we
definite wont design for them. What such an architecture has to do is to
provide the proper do_hr_timer_int() and arch_hrtimer_reprogram()
semantics, via locking around that timer source (naturally), and via
cross-CPU calls - as if they were per-CPU timers.
Ingo
next prev parent reply other threads:[~2005-10-04 5:50 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-28 20:43 tglx
2005-09-28 23:59 ` Frank Sorenson
2005-09-29 0:50 ` Frank Sorenson
2005-09-29 0:56 ` john stultz
2005-09-29 1:05 ` Frank Sorenson
2005-09-29 1:10 ` john stultz
2005-09-29 6:53 ` Thomas Gleixner
2005-09-30 15:58 ` Frank Sorenson
2005-09-29 19:57 ` George Anzinger
2005-10-01 1:03 ` Roman Zippel
2005-10-01 11:22 ` Ingo Molnar
2005-10-04 1:59 ` George Anzinger
2005-10-04 5:51 ` Ingo Molnar [this message]
2005-10-10 12:42 ` Roman Zippel
2005-10-10 14:04 ` Ingo Molnar
2005-10-01 12:05 ` Thomas Gleixner
2005-10-10 17:22 ` Roman Zippel
2005-10-11 7:42 ` Thomas Gleixner
2005-10-12 22:36 ` Roman Zippel
2005-10-12 23:46 ` George Anzinger
2005-10-16 16:34 ` Roman Zippel
2005-10-16 19:26 ` Thomas Gleixner
2005-10-16 23:03 ` Roman Zippel
2005-10-17 7:59 ` Ingo Molnar
2005-10-17 8:26 ` Steven Rostedt
2005-10-17 9:29 ` Roman Zippel
2005-10-17 9:41 ` Ingo Molnar
2005-10-17 9:56 ` Andrew Morton
2005-10-17 11:00 ` Ingo Molnar
2005-10-17 16:25 ` Roman Zippel
2005-10-17 16:49 ` Tim Bird
2005-10-17 17:26 ` Steven Rostedt
2005-10-17 18:49 ` Roman Zippel
2005-10-17 19:19 ` Tim Bird
2005-10-17 19:48 ` Roman Zippel
2005-10-17 20:13 ` Ingo Molnar
2005-10-17 20:31 ` Roman Zippel
2005-10-18 8:46 ` Ingo Molnar
2005-10-18 23:52 ` Tim Bird
2005-10-19 0:03 ` George Anzinger
2005-10-19 1:58 ` Roman Zippel
2005-10-19 6:46 ` Ingo Molnar
2005-10-19 10:49 ` kernel/timer.c design (was: Re: ktimers subsystem) Ingo Molnar
2005-10-19 17:48 ` kernel/timer.c design Tim Bird
2005-10-19 18:00 ` Tim Bird
2005-10-19 19:04 ` Thomas Gleixner
2005-10-19 22:12 ` kernel/timer.c design (was: Re: ktimers subsystem) Roman Zippel
2005-10-19 11:40 ` [PATCH] ktimers subsystem 2.6.14-rc2-kt5 Ingo Molnar
2005-10-19 11:58 ` Ingo Molnar
2005-10-19 22:24 ` Roman Zippel
2005-10-17 20:09 ` Ingo Molnar
2005-10-17 20:55 ` Thomas Gleixner
2005-10-18 0:07 ` Roman Zippel
2005-10-18 1:03 ` George Anzinger
2005-10-19 1:26 ` Roman Zippel
2005-10-19 2:52 ` George Anzinger
2005-10-21 16:22 ` Roman Zippel
2005-10-23 18:17 ` George Anzinger
2005-10-27 20:23 ` Roman Zippel
2005-10-28 4:52 ` Steven Rostedt
2005-10-28 16:06 ` Roman Zippel
2005-10-17 16:33 ` Roman Zippel
2005-10-17 16:39 ` Ingo Molnar
2005-10-17 16:54 ` Roman Zippel
2005-10-17 17:35 ` Ingo Molnar
2005-10-17 9:54 ` Steven Rostedt
2005-10-04 1:55 ` George Anzinger
2005-10-17 18:38 linux
2005-10-17 19:04 ` Roman Zippel
2005-10-17 22:41 ` linux
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=20051004055111.GA20208@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=george@mvista.com \
--cc=hch@infradead.org \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
--cc=paulmck@us.ibm.com \
--cc=tglx@linutronix.de \
--cc=tim.bird@am.sony.com \
--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
Powered by JetHome