From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-arch@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
Rusty Russell <rusty@rustcorp.com.au>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Ingo Molnar <mingo@kernel.org>,
Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1
Date: Fri, 20 Apr 2012 19:26:03 +0530 [thread overview]
Message-ID: <4F916AF3.7020301@linux.vnet.ibm.com> (raw)
In-Reply-To: <20120420122120.097464672@linutronix.de>
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
next prev parent reply other threads:[~2012-04-20 13:56 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 13:05 [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1 Thomas Gleixner
2012-04-20 13:05 ` [patch 01/18] m32r: Remove pointless function prototypes Thomas Gleixner
2012-04-20 13:05 ` [patch 02/18] smp: Add task_struct argument to __cpu_up() Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-23 7:58 ` Jesper Nilsson
2012-04-23 7:58 ` Jesper Nilsson
2012-04-20 13:05 ` [patch 03/18] smp: Add generic smpboot facility Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-20 20:07 ` Yinghai Lu
2012-04-20 20:07 ` Yinghai Lu
2012-04-21 2:07 ` Stephen Rothwell
2012-04-21 2:07 ` Stephen Rothwell
2012-04-20 13:05 ` [patch 04/18] smp: Provide generic idle thread allocation Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-20 16:21 ` Sam Ravnborg
2012-04-20 16:21 ` Sam Ravnborg
2012-04-20 18:55 ` Thomas Gleixner
2012-04-20 18:55 ` Thomas Gleixner
2012-04-21 2:20 ` Stephen Rothwell
2012-04-21 2:20 ` Stephen Rothwell
2012-04-21 2:25 ` Frank Rowand
2012-04-21 2:25 ` Frank Rowand
2012-04-20 13:05 ` [patch 05/18] x86: Add task_struct argument to smp_ops.cpu_up Thomas Gleixner
2012-04-20 13:05 ` [patch 06/18] x86: Use generic idle thread allocation Thomas Gleixner
2012-04-20 13:05 ` [patch 07/18] powerpc: " Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-20 13:05 ` [patch 08/18] ia64: " Thomas Gleixner
2012-04-20 13:05 ` [patch 09/18] arm: " Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-20 13:05 ` [patch 11/18] hexagon: " Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-24 16:47 ` Richard Kuo
2012-04-24 16:47 ` Richard Kuo
2012-04-20 13:05 ` [patch 10/18] mips: " Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-20 13:05 ` [patch 12/18] s390: " Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-23 7:09 ` Martin Schwidefsky
2012-04-23 7:09 ` Martin Schwidefsky
2012-04-20 13:05 ` [patch 13/18] blackfin: " Thomas Gleixner
2012-04-20 13:05 ` [patch 14/18] cris: " Thomas Gleixner
2012-04-23 7:57 ` Jesper Nilsson
2012-04-23 7:57 ` Jesper Nilsson
2012-04-20 13:05 ` [patch 15/18] sh: " Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-21 3:18 ` Paul Mundt
2012-04-20 13:05 ` [patch 16/18] alpha: " Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-20 13:05 ` [patch 17/18] parisc: " Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-20 13:05 ` [patch 18/18] sparc: " Thomas Gleixner
2012-04-20 13:05 ` Thomas Gleixner
2012-04-22 19:52 ` David Miller
2012-04-20 13:16 ` [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1 Thomas Gleixner
2012-04-20 13:21 ` Peter Zijlstra
2012-04-20 13:47 ` Thomas Gleixner
2012-04-21 0:08 ` Suresh Siddha
2012-05-03 9:41 ` Thomas Gleixner
2012-05-03 9:41 ` Thomas Gleixner
2012-05-03 23:42 ` Suresh Siddha
2012-04-20 15:42 ` Tejun Heo
2012-04-20 15:49 ` Peter Zijlstra
2012-04-20 15:56 ` Thomas Gleixner
2012-04-20 13:56 ` Srivatsa S. Bhat [this message]
2012-04-20 14:18 ` Thomas Gleixner
2012-04-24 18:44 ` Konrad Rzeszutek Wilk
2012-05-21 1:42 ` Rusty Russell
2012-05-21 8:25 ` Thomas Gleixner
2012-05-21 8:25 ` Thomas Gleixner
2012-05-22 0:53 ` Rusty Russell
2012-04-20 14:06 ` richard -rw- weinberger
2012-04-20 14:06 ` richard -rw- weinberger
2012-04-20 14:19 ` Thomas Gleixner
2012-04-20 14:27 ` James Bottomley
2012-04-20 17:55 ` Paul E. McKenney
2012-04-20 23:11 ` Venki Pallipadi
2012-04-21 1:04 ` Frank Rowand
2012-04-21 1:55 ` Frank Rowand
2012-04-22 21:01 ` Chris Metcalf
2012-04-22 21:01 ` Chris Metcalf
2012-04-30 8:05 ` Santosh Shilimkar
2012-04-30 8:05 ` Santosh Shilimkar
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=4F916AF3.7020301@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).