From: Sachin Sant <sachinp@in.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: ego@in.ibm.com, LKML <linux-kernel@vger.kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Mike Galbraith <efault@gmx.de>,
Gregory Haskins <ghaskins@novell.com>, maxk <maxk@qualcomm.com>
Subject: Re: -next: Nov 12 - kernel BUG at kernel/sched.c:7359!
Date: Thu, 26 Nov 2009 10:09:12 +0530 [thread overview]
Message-ID: <4B0E0670.2000309@in.ibm.com> (raw)
In-Reply-To: <1259156575.4027.514.camel@laptop>
Peter Zijlstra wrote:
> Correct, Ingo objected to the fastpath overhead.
>
> Could you please try the below patch which tries to address the issue
> differently.
>
Works great. Thanks
Tested-by: Sachin Sant <sachinp@in.ibm.com>
Regards
-Sachin
> ---
> Subject: sched: Fix balance vs hotplug race
> From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Wed Nov 25 13:31:39 CET 2009
>
> Since (e761b77: cpu hotplug, sched: Introduce cpu_active_map and redo
> sched domain managment) we have cpu_active_mask which is suppose to
> rule scheduler migration and load-balancing, except it never did.
>
> The particular problem being solved here is a crash in
> try_to_wake_up() where select_task_rq() ends up selecting an offline
> cpu because select_task_rq_fair() trusts the sched_domain tree to reflect
> the current state of affairs, similarly select_task_rq_rt() trusts the
> root_domain.
>
> However, the sched_domains are updated from CPU_DEAD, which is after
> the cpu is taken offline and after stop_machine is done. Therefore it
> can race perfectly well with code assuming the domains are right.
>
> Cure this by building the domains from cpu_active_mask on
> CPU_DOWN_PREPARE.
>
>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
next prev parent reply other threads:[~2009-11-26 4:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-12 8:51 linux-next: Tree for November 12 Stephen Rothwell
2009-11-12 11:53 ` -next: Nov 12 - kernel BUG at kernel/sched.c:7359! Sachin Sant
2009-11-12 12:10 ` Peter Zijlstra
2009-11-12 12:23 ` Sachin Sant
2009-11-12 12:27 ` Peter Zijlstra
2009-11-12 17:10 ` Peter Zijlstra
2009-11-13 9:00 ` Sachin Sant
2009-11-13 9:06 ` Peter Zijlstra
2009-11-13 9:58 ` Gautham R Shenoy
2009-11-13 10:16 ` Peter Zijlstra
2009-11-13 10:31 ` Peter Zijlstra
2009-11-13 10:49 ` Peter Zijlstra
2009-11-13 11:44 ` Sachin Sant
2009-11-13 16:12 ` Mike Galbraith
2009-11-23 9:53 ` Sachin Sant
2009-11-25 13:42 ` Peter Zijlstra
2009-11-26 4:39 ` Sachin Sant [this message]
2009-12-04 12:06 ` Sachin Sant
2009-12-04 12:16 ` Peter Zijlstra
2009-12-07 6:16 ` Sachin Sant
2009-12-12 7:09 ` Max Krasnyansky
2009-11-12 17:40 ` linux-next: Tree for November 12 (acpi/processor.h) Randy Dunlap
2009-11-12 18:09 ` linux-next: Tree for November 12 (acpi_processor_get_bios_limit) Randy Dunlap
2009-11-12 23:46 ` [PATCH -next] staging/line6: fix printk formats Randy Dunlap
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=4B0E0670.2000309@in.ibm.com \
--to=sachinp@in.ibm.com \
--cc=efault@gmx.de \
--cc=ego@in.ibm.com \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=maxk@qualcomm.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
/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.