Logical CPU Numbering for DLPAR

Dave Engebretsen engebret at vnet.ibm.com
Sat Nov 1 02:46:33 EST 2003


In 2.4 we implemented a logcial cpu numbering design which was changed
to use a physical numbering in 2.5.  This creates a problem when a
partition is configured for DLPAR of processors, so we have been moving
the DLPAR code base back to the original design point.

The fundamental problem with using physical numbers is that the kernel
must assume the platform maximum number of processors and alllocate and
configure all data structures to allow for this.  Even though we do not
do all the right things here yet, I would expect that one uncoming focus
in the kernel will be to free up unused statically allocated per-cpu
data in order to reduce the memory footprint for small partitions while
maintaining single binary compatibilly on large systems.  The problem is
made worse when N-1 support is taken into account.

Note that the platform archicture does not require that firmware create
a logical collection of  processors, and in fact legacy firmware
explicitly does not.logically number processors.  By logically numbering
the processors, we only need to account for the max partition
configuration as defined at partition boot time.

In support of this, a new property has been added to cpu nodes in the
device tree: linux,logical-name (similar to what we have for phbs).
This property allows a binding to be made between a physical processor
(as represented by the reg property of the node) and the logical name
used by Linux.  This is required when the platform specifies a hardware
processor to remove (for example in a gard operation) but the software
stack must select a logical cpu to offline.

It turns out this code we have in the DLPAR tree gets wound up a bit in
the SMT support code, which I'm in the middle of reporting to 2.6, so
I'd like to move to this model in the general tree ASAP.



** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc64-dev mailing list