| Message ID | 1571166368-8078-1-git-send-email-frank.heimes@canonical.com |
|---|---|
| Headers | show |
| Series | Check for CPU Measurement sampling (LP: 1847590) | expand |
On Tue, Oct 15, 2019 at 09:06:07PM +0200, frank.heimes@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@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@canonical.com>
On 15.10.19 21:06, frank.heimes@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@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(-) > Applied to bionic, disco and eoan master-next branches. Thanks, Kleber