[lkml]   [2004]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC/PATCH 0/4] cpus, nodes, and the device model: dynamic cpu registration
    On Sun, Oct 24, 2004 at 03:42:10AM -0600, Nathan Lynch wrote:
    Hi Natan,
    Sorry I am replying to you mail so late as I got to see your mail now:)
    Firstly good to see that some other architecture other than ia64 is planning to
    support physical CPU hotplug. Recenlty I had submitted some patches for supporting
    ACPI based physical cpu hotplug for IA64 arch. I will take a look at you patches and
    give more comments later.

    thanks for your efforts.


    > Hi there-
    > I know of at least two platforms (ppc64 and ia64) which allow cpus to
    > be physically or logically added and removed from a running system.
    > These are distinct operations from onlining or offlining, which is
    > well supported already. Right now there is little support in the core
    > cpu "driver" for dynamic addition or removal. The patch series which
    > follows implements support for this in a way which will (hopefully)
    > reduce code duplication and enforce some uniformity across the
    > relevant architectures.
    > For starters, the current situation is that cpu sysdevs are registered
    > from architecture code at boot. Already we have inconsistencies
    > betweeen the arches -- ia64 registers only online cpus, ppc64
    > registers all "possible" cpus. I propose to move the initial cpu
    > sysdev registrations to the cpu "driver" itself (drivers/base/cpu.c),
    > and to register only "present" cpus at boot.
    > But that breaks all the arch code which explicitly registers cpu
    > sysdevs. For instance, ppc64 wants to hang all kinds of attributes
    > off of the cpu devices for performance counter stuff. So code such as
    > this needs to be converted to register a sysdev_driver with the cpu
    > device class, which will allow the ppc64 code to be notified when a
    > cpu is added or removed. In the patches that follow I include the
    > changes necessary for ppc64, as an example. (An arch sweep or
    > temporary compatibility hack can come later if I get positive
    > responses to this approach.)
    > Also, there is the matter of the base numa "node" driver. Currently
    > the cpu driver makes symlinks from nodes to their cpus. This seems
    > backwards to me, so I have changed the node driver to create or remove
    > the symlinks upon cpu addition or removal, respectively, also using
    > the sysdev_driver approach. I've also converted base/drivers/node.c
    > to doing the boot-time node registration itself, like the cpu code.

    > Finally, I've added two new interfaces which wrap all this up --
    > cpu_add() and cpu_remove(). These carry out the necessary update to
    > cpu_present_map and take care of the cpu device registration. These
    > are meant to be invoked from the platform-specific code which
    > discovers and removes processors.
    > This is the first real device model-related hacking I've done. I'm
    > hoping Greg or Patrick will tell me whether I'm on the right track or
    > abusing the APIs :)
    > These patches have been boot-tested on ppc64. I haven't gotten to
    > test the removal paths yet.
    > Nathan
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > More majordomo info at
    > Please read the FAQ at
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:07    [W:0.024 / U:24.356 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site