]> git.baikalelectronics.ru Git - kernel.git/commit
powerpc/64s: Fix restore_math unnecessarily changing MSR
authorNicholas Piggin <npiggin@gmail.com>
Tue, 23 Jun 2020 23:41:38 +0000 (09:41 +1000)
committerMichael Ellerman <mpe@ellerman.id.au>
Thu, 16 Jul 2020 03:00:24 +0000 (13:00 +1000)
commit956bb296b25d7973db9eeada4e0af08d76a01038
tree1fb46c1eb7638e6037f73ddf2bfc884168595d40
parent81336f2bf5ac90c50ddcbde2b69e0dd6b3c3c8fd
powerpc/64s: Fix restore_math unnecessarily changing MSR

Before returning to user, if there are missing FP/VEC/VSX bits from the
user MSR then those registers had been saved and must be restored again
before use. restore_math will decide whether to restore immediately, or
skip the restore and let fp/vec/vsx unavailable faults demand load the
registers.

Each time restore_math restores one of the FP/VSX or VEC register sets
is loaded, an 8-bit counter is incremented (load_fp and load_vec). When
these wrap to zero, restore_math no longer restores that register set
until after they are next demand faulted.

It's quite usual for those counters to have different values, so if one
wraps to zero and restore_math no longer restores its registers or user
MSR bit but the other is not zero yet does not need to be restored
(because the kernel is not frequently using the FPU), then restore_math
will be called and it will also not return in the early exit check.
This causes msr_check_and_set to test and set the MSR at every kernel
exit despite having no work to do.

This can cause workloads (e.g., a NULL syscall microbenchmark) to run
fast for a time while both counters are non-zero, then slow down when
one of the counters reaches zero, then speed up again after the second
counter reaches zero. The cost is significant, about 10% slowdown on a
NULL syscall benchmark, and the jittery behaviour is very undesirable.

Fix this by having restore_math test all conditions first, and only
update MSR if we will be loading registers.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200623234139.2262227-2-npiggin@gmail.com
arch/powerpc/kernel/process.c
arch/powerpc/kernel/syscall_64.c