On vertical polarization, kernel can be adjusting CPU capacities
dynamically, and cpuplugd can interfere this with hotplug operations
causing performance degradation. To prevent this, check if system has
switched its polarization state, and act accordingly.
If system is on vertical polarization when daemon starts, no CPU hotplug
action is triggered. If system changes to vertical polarization during
daemon runtime, revert cpuhotplug adjustments and stop further CPU
hotplug actions. If system switches back to horizontal polarization
during runtime of the daemon, start evaluating CPU hotplug rules and
trigger adjustments.
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Simplify the cpu management parts of cpuplugd code by introducing
functions from libutil and rework some logic to drop some assumptions
about how kernel assigns cpuids.
Right now cpuplugd assumes that the cpuids are always sequential and
there are no gaps in between, however kernel does not guarantee that.
Make cpuplugd compliant by traversing cpu sysfs entries instead.
Reviewed-by: Steffen Eiden <seiden@linux.ibm.com>
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Mete Durlu <meted@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Currently "systemctl start cpuplugd" does not report any errors in
case the startup fails.
Example:
# mv /etc/cpuplugd.conf /etc/cpuplugd.conf.xxx
# systemctl start cpuplugd
The reason is that for type=simple systemd forks/execs cpuplugd and if
that is successful immediately returns. There is no way to find out
if the initial startup fails.
Fix this by using type=fork and running cpuplugd in the background. In
this case systemd waits until the initial process returns.
In addition use PIDFile and ensure that the pid file is already available
when the initial cpuplugd process returns. To achieve this, replace the
daemon() function by our own implementation that introduces startup
synchronization via pipe. Without that systemd would print the following
warning:
systemd[1]: cpuplugd.service: PID file /var/run/cpuplugd.pid not readable
(yet?) after start: No such file or directory
With this patch, an early startup error like in the example above, is now
reported correctly in "systemctl start":
# systemctl start cpuplugd
Job for cpuplugd.service failed because the control process exited...
See "systemctl status cpuplugd.service" and "journalctl -xe" for ...
# journalctl -ex | grep cpuplugd
Nov 16 15:52:27 ... cpuplugd[5096]: Opening configuration file failed:
No such file or directory
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
This commit is based on the s390-tools-1.39.0 version.
Changes on top of s390-tools-1.39.0:
- Add MIT license to all source files
- Add LICENSE file
- Transform REAMDE to README.md (markdown)
- Add AUTHORS.md file
- Add CONTRIBUTING.md file
- Move changelog from README to CHANGELOG.md file
Reviewed-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
