| Message ID | 20210329161547.1159738-1-frank.heimes@canonical.com |
|---|---|
| Headers | show |
| Series | s390/vtime: fix increased steal time accounting (LP: 1921498) | expand |
Already applied to hirsute/5.11 via stable updates. -Andrea On Mon, Mar 29, 2021 at 06:15:46PM +0200, frank.heimes@canonical.com wrote: > BugLink: https://bugs.launchpad.net/bugs/1921498 > > SRU Justification: > > [Impact] > > * The reported steal time on s390x is erroneously increasing and therefore broken. > > * This problem got introduced with commit 152e9b8676c6e > ("s390/vtime: steal time exponential moving average") - upstream with v5.1 > > [Fix] > > * d54cb7d54877d529bc1e0e1f47a3dd082f73add3 d54cb7d54877 "s390/vtime: fix increased steal time accounting" > > [Test Case] > > * An IBM Z or LinuxONE systems, installed with Ubuntu Server 20.04, 20.10 and 21.04 on LPAR, are needed. > > * The system needs to be configured as KVM host with one or more KVM guests. > > * Now put significant workload on the guest(s), so that the hypervisor starts to 'steal time'. > This can be best forced by having only very limited CPU resources for the hypervisor itself. > > * Start monitoring the steal time, that is reported at /proc/stat, > but can be more easily verified with tools like vmstat or even top. > > * If the steal time starts ever growing (exponentially), the situation is broken. > > * In case the steal time stays relatively constant, > or grows only very limited after a ramp up phase of some minutes, > or just oscillates around a certain value, a fixed/patched kernel is in use. > > [Regression Potential] > > * The patch only changes the single line that calculates: account_steal_time > > * In case the account_steal_time calculation is still broken after the modification, > the steal time is just again not reported correctly on s390x, > but maybe in a different way (rather than exponentially growing). > > * But it will not further harm virtualization on s390x systems. > > * The modification is very limited with that one line change. > > * The commit got upstream accepted with 5.12-rc4. > > [Other] > > * Since the patch is needed for kernel higher than 5.1 and got upstream accepted with 5.12-rc4, > hirsute, groovy and focal are affected. > > * The upstream commit can be cleanly cherry-picked from all three affected Ubuntu releases. > > Gerald Schaefer (1): > s390/vtime: fix increased steal time accounting > > arch/s390/kernel/vtime.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
On Mon, Mar 29, 2021 at 06:15:46PM +0200, frank.heimes@canonical.com wrote:
> BugLink: https://bugs.launchpad.net/bugs/1921498
Already upstream/part of 5.12-rcX.
Applied to Focal and Groovy master-next. Thank you! -Kelsey On 2021-03-29 18:15:46 , frank.heimes@canonical.com wrote: > BugLink: https://bugs.launchpad.net/bugs/1921498 > > SRU Justification: > > [Impact] > > * The reported steal time on s390x is erroneously increasing and therefore broken. > > * This problem got introduced with commit 152e9b8676c6e > ("s390/vtime: steal time exponential moving average") - upstream with v5.1 > > [Fix] > > * d54cb7d54877d529bc1e0e1f47a3dd082f73add3 d54cb7d54877 "s390/vtime: fix increased steal time accounting" > > [Test Case] > > * An IBM Z or LinuxONE systems, installed with Ubuntu Server 20.04, 20.10 and 21.04 on LPAR, are needed. > > * The system needs to be configured as KVM host with one or more KVM guests. > > * Now put significant workload on the guest(s), so that the hypervisor starts to 'steal time'. > This can be best forced by having only very limited CPU resources for the hypervisor itself. > > * Start monitoring the steal time, that is reported at /proc/stat, > but can be more easily verified with tools like vmstat or even top. > > * If the steal time starts ever growing (exponentially), the situation is broken. > > * In case the steal time stays relatively constant, > or grows only very limited after a ramp up phase of some minutes, > or just oscillates around a certain value, a fixed/patched kernel is in use. > > [Regression Potential] > > * The patch only changes the single line that calculates: account_steal_time > > * In case the account_steal_time calculation is still broken after the modification, > the steal time is just again not reported correctly on s390x, > but maybe in a different way (rather than exponentially growing). > > * But it will not further harm virtualization on s390x systems. > > * The modification is very limited with that one line change. > > * The commit got upstream accepted with 5.12-rc4. > > [Other] > > * Since the patch is needed for kernel higher than 5.1 and got upstream accepted with 5.12-rc4, > hirsute, groovy and focal are affected. > > * The upstream commit can be cleanly cherry-picked from all three affected Ubuntu releases. > > Gerald Schaefer (1): > s390/vtime: fix increased steal time accounting > > arch/s390/kernel/vtime.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
BugLink: https://bugs.launchpad.net/bugs/1921498 SRU Justification: [Impact] * The reported steal time on s390x is erroneously increasing and therefore broken. * This problem got introduced with commit 152e9b8676c6e ("s390/vtime: steal time exponential moving average") - upstream with v5.1 [Fix] * d54cb7d54877d529bc1e0e1f47a3dd082f73add3 d54cb7d54877 "s390/vtime: fix increased steal time accounting" [Test Case] * An IBM Z or LinuxONE systems, installed with Ubuntu Server 20.04, 20.10 and 21.04 on LPAR, are needed. * The system needs to be configured as KVM host with one or more KVM guests. * Now put significant workload on the guest(s), so that the hypervisor starts to 'steal time'. This can be best forced by having only very limited CPU resources for the hypervisor itself. * Start monitoring the steal time, that is reported at /proc/stat, but can be more easily verified with tools like vmstat or even top. * If the steal time starts ever growing (exponentially), the situation is broken. * In case the steal time stays relatively constant, or grows only very limited after a ramp up phase of some minutes, or just oscillates around a certain value, a fixed/patched kernel is in use. [Regression Potential] * The patch only changes the single line that calculates: account_steal_time * In case the account_steal_time calculation is still broken after the modification, the steal time is just again not reported correctly on s390x, but maybe in a different way (rather than exponentially growing). * But it will not further harm virtualization on s390x systems. * The modification is very limited with that one line change. * The commit got upstream accepted with 5.12-rc4. [Other] * Since the patch is needed for kernel higher than 5.1 and got upstream accepted with 5.12-rc4, hirsute, groovy and focal are affected. * The upstream commit can be cleanly cherry-picked from all three affected Ubuntu releases. Gerald Schaefer (1): s390/vtime: fix increased steal time accounting arch/s390/kernel/vtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)