lkml.org 
[lkml]   [2012]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1
On Fri, Apr 20, 2012 at 01:05:41PM -0000, Thomas Gleixner wrote:
> Dear all,
>
> I'm working on refactoring the SMP boot and CPU hotplug implementation.
>
> 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.
>
> This converts all architectures except m32r, mn10300, tile and UM to
> the new core facility. These architecture are calling fork_idle() in
> the very early boot code in smp_prepare_cpus() for unknown reasons.
> I haven't analyzed yet, whether this is on purpose or can be moved
> over to the generic facility. It'd be nice if the responsible maintainers
> could look into that as well.

Looks good to me! Ran some brief rcutorture+hotplug tests, and it
did fine on KVM on 32-bit x86.

Thanx, Paul



\
 
 \ /
  Last update: 2012-04-20 19:59    [W:0.317 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site