From: Peter Zijlstra <peterz@infradead.org>
To: Tejun Heo <tj@kernel.org>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org,
Rusty Russell <rusty@rustcorp.com.au>,
Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH 2/4] sched: implement __set_cpus_allowed()
Date: Mon, 31 May 2010 12:01:24 +0200 [thread overview]
Message-ID: <1275300084.27810.21850.camel@twins> (raw)
In-Reply-To: <4C03879A.8030505@kernel.org>
On Mon, 2010-05-31 at 11:55 +0200, Tejun Heo wrote:
> I don't think flushing from CPU_UP_PREPARE would be a good idea.
> There is no guarantee that those works will finish in short (human
> scale) time,
If not, we should cure it by ensuring these works won't be left
lingering I think.
Also, I really don't much care about how fast we can hotplug cycle
things -- its an utter slow path.
> but we can update cpu_active mask before other
> CPU_UP_PREPARE notifiers are executed so that it's symmetrical to cpu
> down path and then this problem goes away the exact same way, right?
Ah, no, we cannot mark it active before its actually up, because at that
time we'll actually try and run stuff on it, which clearly won't work
when its not there to run stuff.
next prev parent reply other threads:[~2010-05-31 10:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-13 10:48 [PATCHSET sched/core] sched: prepare for cmwq Tejun Heo
2010-05-13 10:48 ` [PATCH 1/4] sched: consult online mask instead of active in select_fallback_rq() Tejun Heo
2010-05-31 8:01 ` Peter Zijlstra
2010-05-31 9:48 ` Tejun Heo
2010-05-13 10:48 ` [PATCH 2/4] sched: implement __set_cpus_allowed() Tejun Heo
2010-05-31 8:01 ` Peter Zijlstra
2010-05-31 9:55 ` Tejun Heo
2010-05-31 10:01 ` Peter Zijlstra [this message]
2010-05-31 10:02 ` Peter Zijlstra
2010-05-31 10:06 ` Tejun Heo
2010-05-31 10:15 ` Peter Zijlstra
2010-05-31 10:19 ` Tejun Heo
2010-05-31 10:46 ` Peter Zijlstra
2010-05-31 11:47 ` Tejun Heo
2010-05-13 10:48 ` [PATCH 3/4] sched: refactor try_to_wake_up() Tejun Heo
2010-05-13 10:48 ` [PATCH 4/4] sched: add hooks for workqueue Tejun Heo
2010-05-31 8:01 ` Peter Zijlstra
2010-05-31 9:58 ` Tejun Heo
2010-05-31 10:05 ` Peter Zijlstra
2010-05-31 10:07 ` Tejun Heo
2010-05-17 23:13 ` [PATCHSET sched/core] sched: prepare for cmwq Tejun Heo
2010-05-21 13:25 ` Tejun Heo
2010-05-23 9:05 ` Ingo Molnar
2010-05-23 9:08 ` Tejun Heo
2010-05-23 9:13 ` Ingo Molnar
2010-05-23 9:24 ` Tejun Heo
2010-05-23 10:20 ` Ingo Molnar
2010-05-23 10:26 ` Tejun Heo
2010-05-27 8:26 ` Tejun Heo
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=1275300084.27810.21850.camel@twins \
--to=peterz@infradead.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--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.