The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Mike Galbraith <efault@gmx.de>
Cc: "Amit K. Arora" <aarora@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@elte.hu>,
	Srivatsa Vaddagiri <vatsa@in.ibm.com>,
	Gautham R Shenoy <ego@in.ibm.com>,
	Darren Hart <dvhltc@us.ibm.com>,
	Brian King <brking@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2] Make sure timers have migrated before killing migration_thread
Date: Sun, 23 May 2010 11:13:06 +0200	[thread overview]
Message-ID: <1274605986.1674.1719.camel@laptop> (raw)
In-Reply-To: <1274605638.9340.25.camel@marge.simson.net>

On Sun, 2010-05-23 at 11:07 +0200, Mike Galbraith wrote:
> On Thu, 2010-05-20 at 09:28 +0200, Peter Zijlstra wrote:
> > On Wed, 2010-05-19 at 17:43 +0530, Amit K. Arora wrote:
> > > Alternate Solution considered : Another option considered was to
> > > increase the priority of the hrtimer cpu offline notifier, such that it
> > > gets to run before scheduler's migration cpu offline notifier. In this
> > > way we are sure that the timers will get migrated before migration_call
> > > tries to kill migration_thread. But, this can have some non-obvious
> > > implications, suggested Srivatsa.
> > 
> > 
> > > On Wed, May 19, 2010 at 11:31:55AM +0200, Peter Zijlstra wrote:
> > > > The other problem is more urgent though, CPU_POST_DEAD runs outside of
> > > > the hotplug lock and thus the above becomes a race where we could
> > > > possible kill off the migration thread of a newly brought up cpu:
> > > > 
> > > >  cpu0 - down 2
> > > >  cpu1 - up 2 (allocs a new migration thread, and leaks the old one)
> > > >  cpu0 - post_down 2 - frees the migration thread -- oops!
> > > 
> > > Ok. So, how about adding a check in CPU_UP_PREPARE event handling too ?
> > > The cpuset_lock will synchronize, and thus avoid race between killing of
> > > migration_thread in up_prepare and post_dead events. 
> > > 
> > > Here is the updated patch. If you don't like this one too, do you mind
> > > suggesting an alternate approach to tackle the problem ? Thanks !
> > 
> > Right, so this isn't pretty at all..
> 
> Since the problem seems to stem from interfering with a critical thread,
> how about create a SCHED_SYSTEM_CRITICAL flag ala SCHED_RESET_ON_FORK?
> 
> Not particularly beautiful, and completely untested (well, it compiles).

Nah, I'd rather we pull the migration thread out of SCHED_FIFO and
either schedule it explicit or add a sched_class for it. We need to do
that anyway once we go play with SCHED_DEADLINE.

But it would be very nice if we could simply order the timer and task
migration bits so that the whole problem doesn't exist in the first
place.


  reply	other threads:[~2010-05-23  9:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19  9:05 [PATCH] Make sure timers have migrated before killing migration_thread Amit K. Arora
2010-05-19  9:31 ` Peter Zijlstra
2010-05-19 12:13   ` [PATCH v2] " Amit K. Arora
2010-05-20  7:28     ` Peter Zijlstra
2010-05-23  9:07       ` Mike Galbraith
2010-05-23  9:13         ` Peter Zijlstra [this message]
2010-05-24  6:43       ` Amit K. Arora
2010-05-25 20:19       ` Thomas Gleixner
2010-05-26  6:43         ` Peter Zijlstra
2010-05-24  9:59   ` [PATCH] " Amit K. Arora
2010-05-24 13:28     ` Peter Zijlstra
2010-05-24 15:16       ` Srivatsa Vaddagiri
2010-05-24 15:55         ` Peter Zijlstra
2010-05-25 11:31     ` Peter Zijlstra
2010-05-25 12:10       ` Amit K. Arora
2010-05-25 13:23       ` [PATCH v3] " Amit K. Arora
2010-05-25 14:22         ` Peter Zijlstra
2010-05-25 16:27         ` Tejun Heo
2010-05-31  7:18         ` [tip:sched/urgent] sched: Make sure timers have migrated before killing the migration_thread tip-bot for Amit K. Arora

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=1274605986.1674.1719.camel@laptop \
    --to=peterz@infradead.org \
    --cc=aarora@linux.vnet.ibm.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=dvhltc@us.ibm.com \
    --cc=efault@gmx.de \
    --cc=ego@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=vatsa@in.ibm.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