From: Nathan Lynch <nathanl@austin.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: greg@kroah.com, rusty@rustcorp.com.au, mochel@digitalimplant.org,
Nathan Lynch <nathanl@austin.ibm.com>,
anton@samba.org
Subject: [RFC/PATCH 0/4] cpus, nodes, and the device model: dynamic cpu registration
Date: Sun, 24 Oct 2004 03:42:10 -0600 [thread overview]
Message-ID: <20041024094551.28808.28284.87316@biclops> (raw)
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
next reply other threads:[~2004-10-24 9:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-24 9:42 Nathan Lynch [this message]
2004-10-24 9:42 ` [RFC/PATCH 1/4] dynamic cpu registration - core changes Nathan Lynch
2004-11-05 1:51 ` Ashok Raj
2004-11-09 3:45 ` Nathan Lynch
2004-10-24 9:42 ` [RFC/PATCH 2/4] drivers/base/node.c changes for dynamic cpu registration Nathan Lynch
2004-10-24 9:42 ` [RFC/PATCH 3/4] introduce cpu_add and cpu_remove Nathan Lynch
2004-11-05 1:57 ` Ashok Raj
2004-11-05 23:14 ` Matthew Dobson
2004-10-24 9:42 ` [RFC/PATCH 4/4] ppc64: convert to sysdev_driver Nathan Lynch
2004-10-25 6:12 ` [RFC/PATCH 0/4] cpus, nodes, and the device model: dynamic cpu registration Rusty Russell
2004-10-25 11:20 ` Nathan Lynch
2004-11-05 1:09 ` Ashok Raj
2004-11-09 3:45 ` Nathan Lynch
2004-11-05 1:54 ` Keshavamurthy Anil S
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041024094551.28808.28284.87316@biclops \
--to=nathanl@austin.ibm.com \
--cc=anton@samba.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox