From: Jonas Aaberg <jonas.aberg@stericsson.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Russell King <linux@arm.linux.org.uk>,
Linus WALLEIJ <linus.walleij@stericsson.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: RFC [PATCH] SMP: Don't schedule tasks on inactive cpu(s)
Date: Fri, 2 Mar 2012 11:51:12 +0100 [thread overview]
Message-ID: <4F50A620.1080808@stericsson.com> (raw)
In-Reply-To: <1330516117.11248.138.camel@twins>
Thanks Peter for having a look. I will try to come up with a way to
trigger this issue more easily.
If I find a way, I will test with your original patch,
https://lkml.org/lkml/2011/12/15/255, and tell you the result.
Best regards,
Jonas Aaberg
On 02/29/2012 12:48 PM, Peter Zijlstra wrote:
> On Wed, 2012-02-29 at 12:03 +0100, Peter Zijlstra wrote:
>> On Wed, 2012-02-29 at 11:42 +0100, Jonas Aaberg wrote:
>>> This patch removes the ability to schedule tasks on cpus that are online,
>>> but not active. The reason for this patch is that during cpu hotplug
>>> on ARM (atleast) there is a short window where cpuX (X > 0) is online, but
>>> busy-waiting on cpu0 to put it active, meanwhile cpu0 can be interrupted
>>> and try to schedule something on the cpu that is busy checking its active bit.
>>
>> https://lkml.org/lkml/2011/12/15/255
>>
>> that one?
>>
>> I _think_ its correct, but it would be so good if someone else could
>> verify.
>
> Relevant patches to consider are: e761b772 and 3a101d05.
>
> Having looked at this again, I think we lost something in 3a101d05 since
> it moves cpuset_update_active_cpus() from CPU_DEAD to CPU_DOWN_PREPARE
> (and DOWN_FAILED) -- not that it matters that much. Also this patch does
> leaves me somewhat puzzled as to what cpu_active_mask is for now..
>
> The suggested patch linked above moves setting active to CPU_STARTING
> which is _before_ online. It looks like some parts of the scheduler
> don't look at online at all anymore so that opens a 'window' where we
> could select a cpu that isn't part of the sched_domain nor online
> (select_fallback_rq and cpuset_cpus_allowed_fallback).
>
> Now this isn't really a problem because of stop-machine, by the time
> anybody gets to run again both online and active are set and we should
> be good to go. The bad part is of course us relying on this silly
> stop-machine semantic.
>
> Bah, hotplug is such a pain..
prev parent reply other threads:[~2012-03-02 10:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 10:42 RFC [PATCH] SMP: Don't schedule tasks on inactive cpu(s) Jonas Aaberg
2012-02-29 11:03 ` Peter Zijlstra
2012-02-29 11:48 ` Peter Zijlstra
2012-03-02 10:51 ` Jonas Aaberg [this message]
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=4F50A620.1080808@stericsson.com \
--to=jonas.aberg@stericsson.com \
--cc=linus.walleij@stericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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