Re: [RFC/PATCH 0/4] cpus, nodes, and the device model: dynamic cpu registration

Keshavamurthy Anil S
2004-11-05T01:58:19Z

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.

-Anil

> 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 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/