[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F916AF3.7020301@linux.vnet.ibm.com>
Date: Fri, 20 Apr 2012 19:26:03 +0530
From: "Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To: Thomas Gleixner <tglx@...utronix.de>
CC: LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Rusty Russell <rusty@...tcorp.com.au>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...nel.org>,
Nikunj A Dadhania <nikunj@...ux.vnet.ibm.com>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1
Hi Thomas,
On 04/20/2012 06:35 PM, Thomas Gleixner wrote:
> Dear all,
>
> I'm working on refactoring the SMP boot and CPU hotplug implementation.
>
Awesome!
[Unfortunately I got stuck with some other issues recently and couldn't
dedicate enough time (to come up with working code) so far :-( ]
> The current code has evolved over time into a conglomerate of
> warts. My main goals are to:
>
> - reduce the architecture code by moving repeating constructs to the
> core
>
> - redesigning the handling of per cpu threads. There is no point to
> tear down the threads just to create them again.
>
> - restructuring the notifier facility into a proper tree with
> dependencies to avoid the gazillion of callbacks and moving
> setup/teardown code into the context of the upcoming/dying cpu
>
> The motivation behind this work is the cpu hotplug nightmare which we
> are facing in the RT kernel and the requests from several groups
> (e.g. ARM) to make hotplug more lightweight and faster.
>
> This first part moves the idle thread management for non-boot cpus
> into the core. fork_idle() is called in a workqueue as it is
> implemented in a few architectures already. This is necessary when not
> all cpus are brought up by the early boot code as otherwise we would
> take a ref on the user task VM of the thread which brings the cpu up
> via the sysfs interface.
>
Do you have a git tree where you have made these patches available?
That would be pretty useful, so that we can build on whatever you have
already done.. Myself and Nikunj had some initial design/ideas on reducing
the duplication in architecture code, related to managing the setting
of the cpu in the online mask, sending out CPU_STARTING notifiers etc
from generic code..
Regards,
Srivatsa S. Bhat
--
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