[SRU][B][D][E][Patch 0/1] Check for CPU Measurement sampling (LP: 1847590)
frank.heimes at canonical.com
frank.heimes at canonical.com
Tue Oct 15 19:06:07 UTC 2019
Buglink: https://bugs.launchpad.net/bugs/1847590
SRU Justification:
[Impact]
* Check for CPU Measurement sampling to avoid potential loss of sampling data
[Fix]
* 932bfc5aae08f3cb20c1c9f051542f5933710151 932bfc5 "s390/cpumsf: Check for CPU Measurement sampling"
[Test Case]
* Have an LPAR configured with counter and sampling facilities anabled
* Use lscpumf to check the facilities available for your hardware
* Start a benchmark (like mem_alloc) and execute perf top
* Canonical can only do regression testing, functional testing is currently only doable by IBM
[Regression Potential]
* There is as always some regression potential with having new code in and other code changed
* but this particular change is limited to the s390x architecture,
* again to the counter and sampling facilities, that need to be activated by intention
* and is only for compatibility with the latest and newest hw generation only (z15 and L1III)
[Other Info]
* The fix/patch got upstream accepted with v5.4-rc2, hence it needs to be applied to E, D and B
* The patch/commit neraly applied cleanly for me on E, D and B except a little conflict that is easily solveable
* or can even be even automatically be solved by cherry-pick-ing with '-X theirs'
* This is not relevant for Eoan GA, can be added with the help of an SRU cycle to Eoan post-GA
Thomas Richter (1):
Thomas Richter <tmricht at linux.ibm.com>
arch/s390/include/asm/cpu_mf.h | 7 +++++--
arch/s390/kernel/perf_cpum_sf.c | 6 ++++++
2 files changed, 11 insertions(+), 2 deletions(-)
--
2.7.4
More information about the kernel-team
mailing list