RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 463560 - [LTC 6.0 FEAT] 201132:Dynamic CPU hotplug daemon for System z
Summary: [LTC 6.0 FEAT] 201132:Dynamic CPU hotplug daemon for System z
Keywords:
Status: CLOSED DUPLICATE of bug 462976
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: s390utils
Version: 6.0
Hardware: s390x
OS: All
high
high
Target Milestone: alpha
: 6.0
Assignee: Dan Horák
QA Contact:
URL:
Whiteboard:
Depends On: 462976
Blocks: 356741 519799
TreeView+ depends on / blocked
 
Reported: 2008-09-23 21:21 UTC by IBM Bug Proxy
Modified: 2009-10-21 17:32 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-17 18:05:42 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description IBM Bug Proxy 2008-09-23 21:21:19 UTC
=Comment: #0=================================================
Emily J. Ratliff <emilyr.com> - 2008-09-16 18:03 EDT
1. Feature Overview:
Feature Id:	[201132]
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:
Sponsor:	zSeries
Architectures:
s390x

Arch Specificity: Purely Arch Specific Code
Delivery Mechanism: Direct from community
Category:	zSeries
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: 
John Jarvis
jjarvis

5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, mgrf.com, Boeblingen 49-7031-16-3978

Technical contact(s):
Gonzalo Muelas Serrano, gmuelas.com

IBM Manager:
Thomas Schwarz, t.schwarz.com

Comment 1 Bill Nottingham 2008-10-02 19:54:47 UTC
Is there a reason this is s390 specific, and not able to be used on other virtualization frameworks?

Comment 2 Dan Horák 2008-10-06 08:11:05 UTC
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.

Comment 3 Hans-Joachim Picht 2008-10-06 10:38:07 UTC
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>>

http://linuxvm.org/present/SHARE111/S2590ep.pdf

With best regards,

       --Hans

Comment 4 Bill Nottingham 2008-10-06 18:58:52 UTC
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.

Comment 5 IBM Bug Proxy 2008-10-07 11:31:20 UTC
(In reply to comment #6)
> ------- Comment From notting 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
> 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.
>

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
architecture specific.

With best regards,

Hans

Comment 6 Bill Nottingham 2008-10-07 14:28:22 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=463635#c2, which implies otherwise.

Comment 7 Dan Horák 2008-10-07 14:47:26 UTC
But I have "Access denied" for #463635 ...

Comment 9 Dan Horák 2008-10-07 16:06:36 UTC
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?

Comment 10 Dan Horák 2008-10-16 13:40:56 UTC
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

Comment 11 Shawn Wells 2009-01-15 17:51:41 UTC
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.

Comment 12 IBM Bug Proxy 2009-03-03 19:41:07 UTC
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
s390-tools

Comment 13 John Jarvis 2009-09-17 18:05:42 UTC
duping to package rebase BZ.

*** This bug has been marked as a duplicate of bug 462976 ***


Note You need to log in before you can comment on or make changes to this bug.