public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox