From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.org>, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH/RFC] timer: fix deadlock on cpu hotplug
Date: Wed, 22 Sep 2010 10:37:07 +0200 [thread overview]
Message-ID: <20100922083706.GA2177@osiris.boeblingen.de.ibm.com> (raw)
In-Reply-To: <1285083618.2275.884.camel@laptop>
On Tue, Sep 21, 2010 at 05:40:18PM +0200, Peter Zijlstra wrote:
> On Tue, 2010-09-21 at 17:36 +0200, Tejun Heo wrote:
> > I think this is the second time we're seeing deadlock during cpu down
> > due to RT throttling and timer problem. The rather delicate
> > dependency there makes me somewhat nervous. If possible, I think it
> > would be better if we can simply turn the RT throttling off when
> > cpu_stop kicks in. It's intended to be a mechanism to monopolize all
> > CPU cycles to begin with. Would that be difficult?
>
> I've wanted to pull the whole migration thread out from SCHED_FIFO for a
> while. Doing that is probably the easiest thing.
Something like this?
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 4372ccb..854fd57 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -291,7 +291,6 @@ repeat:
static int __cpuinit cpu_stop_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
- struct sched_param param = { .sched_priority = MAX_RT_PRIO - 1 };
unsigned int cpu = (unsigned long)hcpu;
struct cpu_stopper *stopper = &per_cpu(cpu_stopper, cpu);
struct task_struct *p;
@@ -304,7 +303,6 @@ static int __cpuinit cpu_stop_cpu_callback(struct notifier_block *nfb,
cpu);
if (IS_ERR(p))
return NOTIFY_BAD;
- sched_setscheduler_nocheck(p, SCHED_FIFO, ¶m);
get_task_struct(p);
stopper->thread = p;
break;
...gets stuck nearly immediatly on cpu hotplug stress if the machine is
doing anything but idling around.
I was too lazy to figure out why it got stuck. I'm afraid that with such
a change a new class of bugs will appear.
next prev parent reply other threads:[~2010-09-22 8:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-21 14:20 [PATCH/RFC] timer: fix deadlock on cpu hotplug Heiko Carstens
2010-09-21 15:36 ` Tejun Heo
2010-09-21 15:40 ` Peter Zijlstra
2010-09-22 8:37 ` Heiko Carstens [this message]
2010-09-22 9:22 ` Peter Zijlstra
2010-09-22 14:29 ` Peter Zijlstra
2010-09-23 13:31 ` Heiko Carstens
2010-09-25 0:19 ` Peter Zijlstra
2010-10-11 12:31 ` Peter Zijlstra
2010-10-11 13:51 ` Heiko Carstens
2010-10-18 19:16 ` [tip:sched/core] sched: Create special class for stop/migrate work tip-bot for Peter Zijlstra
2010-09-21 15:39 ` [PATCH/RFC] timer: fix deadlock on cpu hotplug 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=20100922083706.GA2177@osiris.boeblingen.de.ibm.com \
--to=heiko.carstens@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
/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.