From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Nathan Lynch <nathanl@austin.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] cpu: add a CPU_DOWN_PREPARE notifier
Date: Thu, 09 Sep 2004 21:00:00 +1000 [thread overview]
Message-ID: <414037B0.40803@yahoo.com.au> (raw)
In-Reply-To: <41402F73.6060804@yahoo.com.au>
Nick Piggin wrote:
> Rusty Russell wrote:
>
>> On Wed, 2004-09-08 at 22:52, Nick Piggin wrote:
>>
>>> 2/3
>>>
>>> Rusty, can I do this?
>>>
>>> ______________________________________________________________________
>>> Add a CPU_DOWN_PREPARE hotplug CPU notifier. This is needed so we can
>>> dettach all sched-domains before a CPU goes down, thus we can build
>>> domains from online cpumasks, and not have to check for the possibility
>>> of a CPU coming up or going down.
>>
>>
>>
>> And if taking the CPU down fails? If you need this, you need the
>> CPU_DOWN_FAILED as well, unfortunately. Hence I prefer the "do the
>> domain thing while machine is frozen" and sidestep it entirely.
>>
>
> Really? It doesn't need to be run from the stop_machine_run
> context at all - it can happily be done while the system is
> running.
>
> That said, if you really object to CPU_DOWN_PREPARE and CPU_DOWN_FAILED,
> it probably shouldn't be too much work. Should it make the call from
> take_cpu_down?
>
The other thing is, it is actually a lot nicer to have this done while
the machine is running, because then cpu_attach_domain guarantees a
quiescent state, so the attach can be done completely atomically from
the point of view of the rest of the scheduler.
So you can always rely on domains and cpu_online_map staying in synch.
The alternative is more fastpath checking of the cpu_online_map, and
possibly more hotplug locks.
In short, I'd really like to have it done this way.
prev parent reply other threads:[~2004-09-09 11:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 12:50 [PATCH 1/3] sched: trivial changes Nick Piggin
2004-09-08 12:52 ` [PATCH 2/3] cpu: add a CPU_DOWN_PREPARE notifier Nick Piggin
2004-09-08 12:57 ` [PATCH 3/3] sched: cpu hotplug notifier for updating sched domains Nick Piggin
2004-09-08 15:43 ` Nathan Lynch
2004-09-08 15:55 ` [PATCH] fix schedstats null deref in sched_exec Nathan Lynch
2004-09-08 23:45 ` Nick Piggin
2004-09-09 10:23 ` [PATCH 2/3] cpu: add a CPU_DOWN_PREPARE notifier Rusty Russell
2004-09-09 10:24 ` Nick Piggin
2004-09-09 11:00 ` Nick Piggin [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=414037B0.40803@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=nathanl@austin.ibm.com \
--cc=rusty@rustcorp.com.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.