linux-stable.git/arch/s390/kernel/wti.c, branch linux-rolling-stable

s390/wti: Add debugfs file to display missed grace periods per cpu

2024-08-29T20:56:35+00:00

Introduce a new debug file which allows to determine how many warning
track grace periods were missed on each CPU.
The new file can be found as /sys/kernel/debug/s390/wti

It is formatted as:
       CPU0       CPU1   [...]    CPUx
        xyz        xyz   [...]     xyz

Acked-by: Heiko Carstens 
Reviewed-by: Mete Durlu 
Signed-off-by: Tobias Huschle 
Signed-off-by: Vasily Gorbik

s390/wti: Add wti accounting for missed grace periods

2024-08-29T20:56:34+00:00

A virtual CPU that has received a warning-track interrupt may fail to
acknowledge the interrupt within the warning-track grace period.
While this is usually not a problem, it will become necessary to
investigate if there is a large number of such missed warning-track
interrupts. Therefore, it is necessary to track these events.
The information is tracked through the s390 debug facility and can be
found under /sys/kernel/debug/s390dbf/wti/.

The hex_ascii output is formatted as:
  

The values pid and current psw are collected when a warning track
interrupt is received. Symbol is either the kernel symbol matching the
collected psw or redacted to  when running in user space.

Each line represents the currently executing process when a warning
track interrupt was received which was then not acknowledged within its
grace period.

Acked-by: Heiko Carstens 
Reviewed-by: Mete Durlu 
Signed-off-by: Tobias Huschle 
Signed-off-by: Vasily Gorbik

s390/wti: Prepare graceful CPU pre-emption on wti reception

2024-08-29T20:56:34+00:00

When a warning track interrupt is received, the kernel has only a very
limited amount of time to make sure, that the CPU can be yielded as
gracefully as possible before being pre-empted by the hypervisor.

The interrupt handler for the wti therefore unparks a kernel thread
which has being created on boot re-using the CPU hotplug kernel thread
infrastructure. These threads exist per CPU and are assigned the
highest possible real-time priority. This makes sure, that said threads
will execute as soon as possible as the scheduler should pre-empt any
other running user tasks to run the real-time thread.

Furthermore, the interrupt handler disables all I/O interrupts to
prevent additional interrupt processing on the soon-preempted CPU.
Interrupt handlers are likely to take kernel locks, which in the worst
case, will be kept while the interrupt handler is pre-empted from itself
underlying physical CPU. In that case, all tasks or interrupt handlers
on other CPUs would have to wait for the pre-empted CPU being dispatched
again. By preventing further interrupt processing, this risk is
minimized.

Once the CPU gets dispatched again, the real-time kernel thread regains
control, reenables interrupts and parks itself again.

Acked-by: Heiko Carstens 
Reviewed-by: Mete Durlu 
Signed-off-by: Tobias Huschle 
Signed-off-by: Vasily Gorbik