From: Robert Love <rml@tech9.net>
To: Erich Focht <focht@ess.nec.de>
Cc: William Lee Irwin III <wli@holomorphy.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
torvalds@transmeta.com
Subject: Re: [PATCH] migration thread fix
Date: 18 Apr 2002 18:38:29 -0400 [thread overview]
Message-ID: <1019169510.5395.126.camel@phantasy> (raw)
In-Reply-To: <Pine.LNX.4.44.0204182358450.3004-100000@beast.local>
On Thu, 2002-04-18 at 18:24, Erich Focht wrote:
> The first thread starts up on the boot cpu with cpus_allowed mask set
> to the boot cpu. It will write itself into cpu_rq(0)->migration_thread
> and be fully functional because all other existing threads (and
> migration_init) will call yield() or schedule(). The other
> migration_threads can also run only on cpu#0 and will do so when
> migration_CPU0 was completely initialized. Then they move themselves
> to their designated CPU by calling set_cpus_allowed(). Their initial
> CPU mask beeing 1<<0, they will call migration_CPU0, which is fully
> functional at this time and only does the job it was designed
> for. There is no dependency on the load balancer any more.
This seems right. I was skeptical because it is very easy here to rely
on some implicit behavior that is not at all defined. I cannot think of
anything wrong with your approach - good.
> I saw the problem #1 when testing an interface to
> userspace which migrates tasks from one cpu to another. It happens
> pretty easilly that the timer interrupt occurs while the migration
> thread is doing its job and holds the current runqueue
> lock. scheduler_tick() spinlocks on the own rq->lock which will never
> be released by migration_thread. Maybe this occurs pretty seldomly on
> IA32 with 10ms ticks, in IA64 it's easy to produce.
Oh, this is indeed a problem. But perhaps the bigger question is, why
does not double_rq_lock disable interrupts like task_rq_lock? You are
right about rq_lock vs. interrupts - thus interrupts must _always_ be
disabled when holding a runqueue lock.
The only other code that uses double_rq_lock is init_idle, which
correctly disables interrupts. Maybe it is wise to just make
double_rq_lock disable interrupts? If not, at least a comment above the
code: "must disable interrupts before calling!".
Also, this is almost certainly the cause of the preempt race in
set_cpus_allowed. I knew it was not kernel preemptions fault!
Robert Love
next prev parent reply other threads:[~2002-04-18 22:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-18 20:08 [PATCH] migration thread fix Erich Focht
2002-04-18 21:28 ` William Lee Irwin III
2002-04-18 21:41 ` Robert Love
2002-04-18 22:07 ` Anton Blanchard
2002-04-18 22:27 ` Robert Love
2002-04-18 22:24 ` Erich Focht
2002-04-18 22:38 ` Robert Love [this message]
2002-04-18 23:27 ` William Lee Irwin III
2002-04-19 1:51 ` Erich Focht
2002-04-19 2:30 ` William Lee Irwin III
2002-04-19 8:09 ` Erich Focht
2002-04-19 4:31 ` Ingo Molnar
2002-04-19 6:40 ` William Lee Irwin III
2002-04-19 4:41 ` Ingo Molnar
2002-04-19 6:48 ` William Lee Irwin III
2002-04-19 4:48 ` Ingo Molnar
2002-04-19 6:56 ` William Lee Irwin III
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=1019169510.5395.126.camel@phantasy \
--to=rml@tech9.net \
--cc=focht@ess.nec.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@transmeta.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.