[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1207251054420.2008-100000@iolanthe.rowland.org>
Date: Wed, 25 Jul 2012 10:57:18 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
cc: tglx@...utronix.de, <mingo@...nel.org>, <peterz@...radead.org>,
<rusty@...tcorp.com.au>, <paulmck@...ux.vnet.ibm.com>,
<namhyung@...nel.org>, <tj@...nel.org>, <rjw@...k.pl>,
<nikunj@...ux.vnet.ibm.com>, <linux-pm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/6] CPU hotplug: Reverse invocation of notifiers
during CPU hotplug
On Wed, 25 Jul 2012, Srivatsa S. Bhat wrote:
> Hi,
>
> This patchset implements the approach of invoking the CPU hotplug callbacks
> (notifiers) in one order during CPU online and in the reverse order during CPU
> offline. The rationale behind this is that services for a CPU are started in a
> particular order (perhaps, with implicit dependencies between them) while
> bringing up the CPU, and hence, it makes sense to tear down the services in
> the opposite order, thereby honoring most of the dependencies automatically
> (and also correctly). This is explained in more detail in Patch 6.
This strongly suggests that a notifier chain may be the wrong mechanism
to use here. Notifiers provide only limited guarantees about ordering,
and it's hard to say much about the services a particular chain will
provide since callbacks can be added from anywhere.
Instead of adding all this complication to the notifier mechanism, how
about using something else for CPU hotplug?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists