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 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.