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.
next prev parent 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