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

[Keshavamurthy Anil S]

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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/