Red Hat Bugzilla – Bug 463560
[LTC 6.0 FEAT] 201132:Dynamic CPU hotplug daemon for System z
Last modified: 2009-10-21 13:32:48 EDT
Emily J. Ratliff <firstname.lastname@example.org> - 2008-09-16 18:03 EDT
1. Feature Overview:
Feature Id: 
a. Name of Feature: Dynamic CPU hotplug daemon for System z
b. Feature Description
A daemon monitoring workload and plugs and unplugs (virtual) CPUs driven by current demand for
processing units. This dynamic hotplug daemon for workload optimization in a SMP environment -
should be part of s390-tools.
2. Feature Details:
Arch Specificity: Purely Arch Specific Code
Delivery Mechanism: Direct from community
Request Type: Package - Feature from IBM
d. Upstream Acceptance: Accepted
Sponsor Priority 1
f. Severity: High
IBM Confidential: no
Code Contribution: IBM code
g. Component Version Target: s390tools 1.6.3
Performance Assistance: yes
3. Business Case
This is a requirement from customers that want to run game servers on Linux on System z.
4. Primary contact at Red Hat:
5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, email@example.com, Boeblingen 49-7031-16-3978
Gonzalo Muelas Serrano, firstname.lastname@example.org
Thomas Schwarz, email@example.com
Is there a reason this is s390 specific, and not able to be used on other virtualization frameworks?
from the cpuplugd manpage:
This program is useful when executed within a z/VM or LPAR Linux environment. The CMM feature (memory hotplug) can not be used inside an LPAR environment.
The memory hotplug requires CMM which is available only when running under z/VM (but other virtualization environments could provide similar features?), but IMHO the cpu hotplug can be used generally.
Adding Hans into CC as he is the developer of this utility.
This feature is currently only useful on s390. Whereas a generic interface for cpu hotplug is used, the cmm feature (for memory hotplug) is only available on s390.
The cpu hotplug functionality can also be used in other virtualization environments. we're currently testing if there'll also be a similar performance advantage as the one we've observed while running inside the z/VM oder LPAR hypervisor.
Whereas existing cpu hotplug tools are typically used to enable or disable cpus based on static system limits, this tool includes a rule based setup which allows a very fine grained configuration.
The primary reason for you to accept this feature should be the fact that this daemon can be used (with a descent configuration) to reduce hardware requirements and to result in a increased system performance.
The following is a quote form our performance department related to this program:
<<Up to 40% more throughput, up to 40% CPU cost savings>>
With best regards,
Right, but the idea is to do things in a generic way as possible, so we don't have
- "configure your x86 servers to do XYZ"
- "but configure your s390 servers to do ABC instead"
Memory hotplug is also in the generic kernel as well, so I'm still confused as to why it's s390 specific.
(In reply to comment #6)
> ------- Comment From firstname.lastname@example.org 2008-10-06 14:58:52 EDT-------
> Right, but the idea is to do things in a generic way as possible, so we don't
> - "configure your x86 servers to do XYZ"
> - "but configure your s390 servers to do ABC instead"
> Memory hotplug is also in the generic kernel as well, so I'm still confused as
> to why it's s390 specific.
The problem here is that a mainframe can hardly be compared with a x86 box...
When it comes to memory hotplug this daemon uses the CONFIG_CMM kernel option which is
With best regards,
See https://bugzilla.redhat.com/show_bug.cgi?id=463635#c2, which implies otherwise.
But I have "Access denied" for #463635 ...
Couldn't be the CMM compared to controlling the memory balloon driver in Xen, where z/VM is Dom0 and Linux/s390 in a VM is DomU? And kernel memory hotplug mechanism is then only reacting on changes in "virtual physical" memory?
My understanding is following:
- guest is configured with 512 MB of memory
- during operation no more then 384 MB are used
- guest (or better the cpuplugd daemon) decides to return 128 MB to its hypervisor
- if memory utilization gets higher it asks the hypervisor for additional memory
or I am wrong?
CPU hotplug in XEN is being added into kernel 2.6.28 - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d68d82afd4c8
Is there an update on this?
From reviewing the comments thus far, my understanding is that this code is upstream (per comment #0). It looks like the s390x code was in 2.6.27 (comment #8), however x86 additions were made and committed into 2.6.28 (comment #10).
Based upon that, it looks like this is on schedule for RHEL6.0 inclusion. What are the next steps?
Reason for asking:
- IBM System z management is asking for status
- Customer interest from US Gov't
Just want to make sure I convey the proper messages & status.
The code for this feature get delivered in s390-tools with feature request:
48095 - RHBZ 462976 [LTC 6.0 FEAT] 201674: Pick up latest version of
duping to package rebase BZ.
*** This bug has been marked as a duplicate of bug 462976 ***