From: Steven Rostedt <rostedt@goodmis.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.13-rc6-rt6
Date: Wed, 17 Aug 2005 13:32:47 -0400 [thread overview]
Message-ID: <1124299967.5764.187.camel@localhost.localdomain> (raw)
In-Reply-To: <20050817064750.GA8395@elte.hu>
On Wed, 2005-08-17 at 08:47 +0200, Ingo Molnar wrote:
> but stop_machine() looks quite preempt-unsafe to begin with. The
> local_irq_disable() would not be needed at all if prior the
> for_each_online_cpu() loop we'd use set_cpus_allowed. The current method
> of achieving 'no preemption' is simply racy even during normal
> CONFIG_PREEMPT.
The code does look flakey, but I think it still works, and it may need
to have a raw_local_irq_disable.
The do_stop is bound to a CPU when it was created, so it doesn't need to
have a set_cpus_allowed.
I guess this is what is happening:
---
You start do_stop in a thread on the cpu that you want to run a function
on. (it's bound to that cpu)
do_stop creates a thread on all the other cpus that will run
stopmachine.
While it creates the threads, the ones that are already created yield in
case a thread wakes up on its cpu, so that that thread can migrate to
its own cpu. (all the threads are at FIFO MAX_RT_PRIO-1, so they should
never be preempted.
After all the threads are created and acknowledge themselves, the
do_stop changes the state to PREPARE.
In stopmachine, when PREPARE is seen, it turns off preemption and stops
yielding.
do_stop then changes the state to DISABLE_IRQ.
In stopmachine, when DISABLE_IRQ is seen, it disables IRQs.
Then the do_stop runs the function that is expected to run in the
STOPPED STATE.
---
Notes:
Each time the state is changed, the ack counter is zeroed and it wont
continue until all the threads acknowledge they hit the expected point.
I'm currious why it needs to go to preempt disable before going to
irqs_disabled? It seems that once it is at the point to go, all
processes should be locked on their CPUS and it would only need to goto
irqs_disable.
I'm also assuming that whatever function is being run expects to have
interrupts off on all CPUs. So a raw_local_irq_disable may be in order.
The comment above the stop_machine (called by do_stop) local_irq_disable
looks incorrect. It says
/* Don't schedule us away at this point, please */ I don't see how it
can be scheduled out if it is running FIFO MAX_RT_PRIO-1. It just
assume that it doesn't want any interrupts to go off.
Do you still see a problem with stop_machine?
-- Steve
next prev parent reply other threads:[~2005-08-17 17:33 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-16 12:18 2.6.13-rc6-rt3 Ingo Molnar
2005-08-16 15:31 ` 2.6.13-rc6-rt5 Steven Rostedt
2005-08-16 15:44 ` 2.6.13-rc6-rt5 Steven Rostedt
2005-08-16 16:08 ` 2.6.13-rc6-rt5 Steven Rostedt
2005-08-16 16:16 ` 2.6.13-rc6-rt5 Ingo Molnar
2005-08-16 16:22 ` 2.6.13-rc6-rt5 Ingo Molnar
2005-08-16 16:32 ` 2.6.13-rc6-rt5 Ingo Molnar
2005-08-16 16:37 ` 2.6.13-rc6-rt5 Ingo Molnar
2005-08-16 16:52 ` 2.6.13-rc6-rt5 Ingo Molnar
2005-08-16 17:08 ` 2.6.13-rc6-rt6 Ingo Molnar
2005-08-16 17:50 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-16 18:07 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-16 18:50 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-17 4:20 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-17 5:46 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-17 6:47 ` 2.6.13-rc6-rt6 Ingo Molnar
2005-08-17 14:05 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-17 14:24 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-17 16:13 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-17 16:23 ` 2.6.13-rc6-rt6 Ingo Molnar
2005-08-17 17:10 ` 2.6.13-rc6-rt6 K.R. Foley
2005-08-17 18:31 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-17 19:31 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-18 0:02 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-18 2:44 ` 2.6.13-rc6-rt6 Steven Rostedt
[not found] ` <20050822075012.GB19386@elte.hu>
[not found] ` <1124704837.5208.22.camel@localhost.localdomain>
[not found] ` <20050822101632.GA28803@elte.hu>
[not found] ` <1124710309.5208.30.camel@localhost.localdomain>
[not found] ` <20050822113858.GA1160@elte.hu>
[not found] ` <1124715755.5647.4.camel@localhost.localdomain>
[not found] ` <20050822183355.GB13888@elte.hu>
2005-08-22 19:40 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-22 19:44 ` [RFC] RT-patch update to remove the global pi_lock Steven Rostedt
2005-08-22 22:19 ` Daniel Walker
2005-08-23 0:26 ` Steven Rostedt
2005-08-23 0:51 ` Daniel Walker
2005-08-23 1:32 ` Steven Rostedt
2005-08-23 3:38 ` Steven Rostedt
[not found] ` <1124908080.5604.22.camel@localhost.localdomain>
[not found] ` <1124917003.5711.8.camel@localhost.localdomain>
2005-08-24 21:05 ` Thomas Gleixner
2005-08-25 1:13 ` Steven Rostedt
2005-08-25 1:38 ` Daniel Walker
2005-08-25 1:48 ` Steven Rostedt
2005-08-25 6:31 ` Ingo Molnar
2005-08-25 6:35 ` Ingo Molnar
2005-08-25 16:15 ` Steven Rostedt
2005-08-25 19:34 ` Ingo Molnar
2005-08-25 19:46 ` Steven Rostedt
2005-08-23 5:29 ` Ingo Molnar
2005-08-25 14:47 ` Steven Rostedt
2005-08-25 15:06 ` Steven Rostedt
2005-08-25 17:47 ` Ingo Molnar
2005-08-25 20:09 ` Steven Rostedt
2005-08-25 21:32 ` Daniel Walker
2005-08-26 2:23 ` Steven Rostedt
2005-08-26 13:52 ` Steven Rostedt
2005-08-30 15:00 ` Steven Rostedt
2005-08-30 15:52 ` Steven Rostedt
2005-08-30 23:08 ` Steven Rostedt
2005-08-31 15:01 ` [FYI] 2.6.13-rt3 and a nanosleep jitter test Steven Rostedt
2005-08-31 15:12 ` Daniel Walker
2005-08-31 15:30 ` Steven Rostedt
2005-08-31 15:13 ` Daniel Walker
2005-08-31 15:19 ` Steven Rostedt
2005-08-31 15:30 ` Daniel Walker
2005-08-23 5:46 ` 2.6.13-rc6-rt6 Ingo Molnar
2005-08-19 21:22 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-19 22:47 ` 2.6.13-rc6-rt6 Paul E. McKenney
2005-08-19 23:02 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-19 23:12 ` 2.6.13-rc6-rt6 Paul E. McKenney
2005-08-19 23:20 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-19 23:44 ` 2.6.13-rc6-rt6 Paul E. McKenney
2005-08-22 7:53 ` 2.6.13-rc6-rt6 Ingo Molnar
2005-08-17 19:27 ` 2.6.13-rc6-rt6 Ingo Molnar
2005-08-17 19:39 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-17 17:32 ` Steven Rostedt [this message]
2005-08-17 19:34 ` 2.6.13-rc6-rt6 Steven Rostedt
2005-08-17 5:59 ` 2.6.13-rc6-rt6 Ingo Molnar
2005-08-17 20:01 ` 2.6.13-rc6-rt8 Peter Bortas
2005-08-23 6:14 ` 2.6.13-rc6-rt8 Ingo Molnar
2005-08-28 20:36 ` 2.6.13-rc6-rt8 Peter Bortas
2005-08-18 9:57 ` 2.6.13-rc6-rt3 Alistair John Strachan
2005-08-18 10:00 ` 2.6.13-rc6-rt3 Thomas Gleixner
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=1124299967.5764.187.camel@localhost.localdomain \
--to=rostedt@goodmis.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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