lkml.org 
[lkml]   [2012]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [patch 00/18] SMP: Boot and CPU hotplug refactoring - Part 1
    From
    On Fri, Apr 20, 2012 at 6:05 AM, Thomas Gleixner <tglx@linutronix.de> 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.
    >

    I had sent out a patchset that did this cleanup here:
    https://lkml.org/lkml/2012/3/6/466

    This patchset is clean and more exhaustive than what I had. So,

    Acked-by: Venkatesh Pallipadi <venki@google.com>

    > 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.
    >
    > Thanks,
    >
    >        tglx
    >
    >
    >
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at  http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at  http://www.tux.org/lkml/
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-04-21 01:15    [W:0.029 / U:91.584 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site