s390: improve wait logic of stop_machine
authorMartin Schwidefsky <schwidefsky@de.ibm.com>
Fri, 17 May 2019 10:50:42 +0000 (12:50 +0200)
committerHeiko Carstens <heiko.carstens@de.ibm.com>
Sat, 15 Jun 2019 10:25:52 +0000 (12:25 +0200)
commit38f2c691a4b3e89d476f8e8350d1ca299974b89d
tree8b4ab76fd8281be6dfcf8d5edc48d5ee522a4710
parent7928260539f3a13b5b23a3fa0a7c0e4f5255940b
s390: improve wait logic of stop_machine

The stop_machine loop to advance the state machine and to wait for all
affected CPUs to check-in calls cpu_relax_yield in a tight loop until
the last missing CPUs acknowledged the state transition.

On a virtual system where not all logical CPUs are backed by real CPUs
all the time it can take a while for all CPUs to check-in. With the
current definition of cpu_relax_yield a diagnose 0x44 is done which
tells the hypervisor to schedule *some* other CPU. That can be any
CPU and not necessarily one of the CPUs that need to run in order to
advance the state machine. This can lead to a pretty bad diagnose 0x44
storm until the last missing CPU finally checked-in.

Replace the undirected cpu_relax_yield based on diagnose 0x44 with a
directed yield. Each CPU in the wait loop will pick up the next CPU
in the cpumask of stop_machine. The diagnose 0x9c is used to tell the
hypervisor to run this next CPU instead of the current one. If there
is only a limited number of real CPUs backing the virtual CPUs we
end up with the real CPUs passed around in a round-robin fashion.

[heiko.carstens@de.ibm.com]:
    Use cpumask_next_wrap as suggested by Peter Zijlstra.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
arch/s390/include/asm/processor.h
arch/s390/kernel/processor.c
arch/s390/kernel/smp.c
include/linux/sched.h
kernel/stop_machine.c