ACK: [SRU][B][D][E][Patch 0/1] Check for CPU Measurement sampling (LP: 1847590)

[Andrea Righi]

On Tue, Oct 15, 2019 at 09:06:07PM +0200, frank.heimes at canonical.com wrote:
> 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(-)

This looks reasonable to me.

Acked-by: Andrea Righi <andrea.righi at canonical.com>