From: Jamie Lokier <jamie@shareable.org>
To: William Lee Irwin III <wli@holomorphy.com>,
G?bor L?n?rt <lgb@lgb.hu>,
Stuart Longland <stuartl@longlandclan.hopto.org>,
Stephan von Krawczynski <skraw@ithnet.com>,
Fabian.Frederick@prov-liege.be, linux-kernel@vger.kernel.org
Subject: Re: 2.7 thoughts
Date: Fri, 10 Oct 2003 16:12:31 +0100 [thread overview]
Message-ID: <20031010151231.GD28795@mail.shareable.org> (raw)
In-Reply-To: <20031010144723.GC727@holomorphy.com>
William Lee Irwin III wrote:
> You need at least enough warning to get out of critical sections (e.g.
> holding a spinlock) and dump registers out to memory. i.e. as long as it
> takes to schedule out whatever's currently running on the thing.
>
> ... and unless you want to start enforcing realtime bounds, the answer
> to "how long do you have to give the kernel to do it?" is "forever".
> In practice, it won't take forever, but no finite time is enforcible.
You can create a very peculiar scheduling state to make even
spinlocked sections multi-task, so the CPU can be released in a finite
time and quickly - about as quickly as taking an NMI and broadcasting
the critical IPIs to tell other CPUs to take over.
The peculiar state is restored to normal as soon as the number
of concurrent critical sections no longer exceeds the number of real CPUs.
Come to think of it, this would be an excellent HA mechanism: CPU or
node detects hardware fault, raises NMI which saves the CPU registers,
does the IPIs and then immediately disables the CPU. That's _it_.
The peculiar scheduling state obviously slows down the code which is
unlucky enough to be caught in a critical section when a CPU is
removed, so if there is _timing_ critical code it will be affected,
but that is a similar problem to speedstep etc.
-- Jamie
next prev parent reply other threads:[~2003-10-10 15:14 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-09 8:08 2.7 thoughts Frederick, Fabian
2003-10-09 8:55 ` John Bradford
2003-10-09 9:45 ` mario noioso
2003-10-09 11:58 ` Gábor Lénárt
2003-10-09 14:57 ` Stephan von Krawczynski
2003-10-10 6:19 ` Stuart Longland
2003-10-10 6:30 ` William Lee Irwin III
2003-10-10 7:30 ` YoshiyaETO
2003-10-10 7:40 ` William Lee Irwin III
2003-10-10 8:47 ` YoshiyaETO
2003-10-10 9:09 ` William Lee Irwin III
2003-10-10 10:26 ` YoshiyaETO
2003-10-10 10:50 ` William Lee Irwin III
2003-10-10 10:55 ` William Lee Irwin III
2003-10-10 10:51 ` Stephan von Krawczynski
2003-10-10 14:07 ` Stuart Longland
2003-10-10 14:27 ` Stephan von Krawczynski
2003-10-10 14:35 ` Gábor Lénárt
2003-10-10 14:47 ` William Lee Irwin III
2003-10-10 14:48 ` Mark Mielke
2003-10-10 15:01 ` William Lee Irwin III
2003-10-10 15:50 ` Mark Mielke
2003-10-10 16:35 ` Chris Friesen
2003-10-10 16:44 ` William Lee Irwin III
2003-10-12 20:14 ` Pavel Machek
2003-10-10 15:12 ` Jamie Lokier [this message]
2003-10-10 15:21 ` William Lee Irwin III
2003-10-10 18:03 ` Tim Hockin
2003-10-10 18:29 ` William Lee Irwin III
2003-10-10 18:56 ` Tim Hockin
2003-10-10 23:40 ` Rusty Russell
2003-10-15 19:15 ` Anton Blanchard
2003-10-10 13:30 ` Kevin Corry
2003-10-10 18:29 ` Lars Marowsky-Bree
2003-10-11 3:49 ` jw schultz
2003-10-11 13:24 ` Lars Marowsky-Bree
2003-10-11 19:50 ` jw schultz
2003-10-10 17:12 ` Matt Simonsen
2003-10-10 20:59 ` Pedro Larroy
2003-10-09 18:17 ` Greg KH
2003-10-09 19:07 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2003-10-09 11:56 Svetoslav Slavtchev
2003-10-09 12:44 Xose Vazquez Perez
2003-10-09 13:17 Frederick, Fabian
2003-10-09 13:19 ` Jens Axboe
2003-10-09 13:50 ` Gábor Lénárt
2003-10-09 13:52 ` Bartlomiej Zolnierkiewicz
2003-10-10 19:01 Zwane Mwaikambo
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=20031010151231.GD28795@mail.shareable.org \
--to=jamie@shareable.org \
--cc=Fabian.Frederick@prov-liege.be \
--cc=lgb@lgb.hu \
--cc=linux-kernel@vger.kernel.org \
--cc=skraw@ithnet.com \
--cc=stuartl@longlandclan.hopto.org \
--cc=wli@holomorphy.com \
/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