[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