kunit: irq: Continue increasing hrtimer interval for longer
Subsystems (3)
PATCH 1/1 kunit: irq: Continue increasing hrtimer interval for longer
Currently, kunit_irq_test_timer_func() stops increasing the hrtimer interval as soon as some forward progress is made in each of softirq and task context. Update it to use a more aggressive strategy: increase the interval as long as the hrtimer is running significantly faster than either context.
This resolves an occasional hang in the CRC and crypto library tests under qemu-system-s390x. It was exposed by the change in the default preemption model on s390 from NONE to LAZY. That seems to have exposed the issue by allowing some forward progress to be made while the actual system timer tick is still starved, preventing jiffies from increasing or the task context from making much progress towards max_iterations.
---
This patch is targeting libcrypto-next
include/kunit/run-in-irq-context.h | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
include/kunit/run-in-irq-context.h +6 -4
@@ -38,11 +38,13 @@ static enum hrtimer_restart kunit_irq_test_timer_func(struct hrtimer *timer) softirq_calls =atomic_read (&state->softirq_func_calls);/* -* If the timer is firing too often for the softirq or task to ever have -* a chance to run, increase the timer interval. This is needed on very -* slow systems. +* If the hrtimer is running much faster than the bh_work or the task, +* then it is firing too fast and might be starving those contexts as +* well as the actual system timer tick. Increase the interval. */ -if (hardirq_calls >=20 && (softirq_calls ==0 || task_calls ==0 )) +if (hardirq_calls >=20 && + (hardirq_calls /2 > softirq_calls || + hardirq_calls /2 > task_calls)) state->interval =ktime_add_ns (state->interval,250 );if (!state->func (state->test_specific_state))
base-commit: 6d22ec26295c1412d765e3d687e46224fc332928
Signature · 1 line
2.55.0
Quoted 46 lines · Eric Biggers
Currently,
kunit_irq_test_timer_func()stops increasing the hrtimer interval as soon as some forward progress is made in each of softirq and task context. Update it to use a more aggressive strategy: increase the interval as long as the hrtimer is running significantly faster than either context.This resolves an occasional hang in the CRC and crypto library tests under qemu-system-s390x. It was exposed by the change in the default preemption model on s390 from NONE to LAZY. That seems to have exposed the issue by allowing some forward progress to be made while the actual system timer tick is still starved, preventing jiffies from increasing or the task context from making much progress towards
max_iterations.Fixes 201ceb94aa1d ("kunit: irq: Ensure timer doesn't fire too frequently")Signed-off-by Eric Biggers <[email protected]>---
This patch is targeting libcrypto-next
include/kunit/run-in-irq-context.h | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)include/kunit/run-in-irq-context.h +6
-4@@ -38,11 +38,13 @@ static enum hrtimer_restart kunit_irq_test_timer_func(struct hrtimer *timer) softirq_calls =atomic_read (&state->softirq_func_calls);/* -* If the timer is firing too often for the softirq or task to ever have -* a chance to run, increase the timer interval. This is needed on very -* slow systems. +* If the hrtimer is running much faster than the bh_work or the task, +* then it is firing too fast and might be starving those contexts as +* well as the actual system timer tick. Increase the interval. */ -if (hardirq_calls >=20 && (softirq_calls ==0 || task_calls ==0 )) +if (hardirq_calls >=20 && + (hardirq_calls /2 > softirq_calls || + hardirq_calls /2 > task_calls)) state->interval =ktime_add_ns (state->interval,250 );
Quoted 2 lines
if (!state->func(state->test_specific_state))
Le 04/08/2026 à 02:18, Eric Biggers a écrit :
Quoted 13 lines
Currently,
kunit_irq_test_timer_func()stops increasing the hrtimer interval as soon as some forward progress is made in each of softirq and task context. Update it to use a more aggressive strategy: increase the interval as long as the hrtimer is running significantly faster than either context.This resolves an occasional hang in the CRC and crypto library tests under qemu-system-s390x. It was exposed by the change in the default preemption model on s390 from NONE to LAZY. That seems to have exposed the issue by allowing some forward progress to be made while the actual system timer tick is still starved, preventing jiffies from increasing or the task context from making much progress towards
max_iterations.
Quoted 7 lines
Fixes 201ceb94aa1d ("kunit: irq: Ensure timer doesn't fire too frequently")Signed-off-by Eric Biggers <[email protected]>---
This patch is targeting libcrypto-next
Thanks. Nothing else is touching this, so taking it through libcrypto-next is fine.
Cheers,
-- David
Quoted 27 lines
include/kunit/run-in-irq-context.h | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)include/kunit/run-in-irq-context.h +6
-4@@ -38,11 +38,13 @@ static enum hrtimer_restart kunit_irq_test_timer_func(struct hrtimer *timer) softirq_calls =atomic_read (&state->softirq_func_calls);/* -* If the timer is firing too often for the softirq or task to ever have -* a chance to run, increase the timer interval. This is needed on very -* slow systems. +* If the hrtimer is running much faster than the bh_work or the task, +* then it is firing too fast and might be starving those contexts as +* well as the actual system timer tick. Increase the interval. */ -if (hardirq_calls >=20 && (softirq_calls ==0 || task_calls ==0 )) +if (hardirq_calls >=20 && + (hardirq_calls /2 > softirq_calls || + hardirq_calls /2 > task_calls)) state->interval =ktime_add_ns (state->interval,250 );if (!state->func (state->test_specific_state))base-commit:
6d22ec26295c1412d765e3d687e46224fc332928
Eric Biggers
AppliedQuoted 13 lines · Eric Biggers
Currently,
kunit_irq_test_timer_func()stops increasing the hrtimer interval as soon as some forward progress is made in each of softirq and task context. Update it to use a more aggressive strategy: increase the interval as long as the hrtimer is running significantly faster than either context.This resolves an occasional hang in the CRC and crypto library tests under qemu-system-s390x. It was exposed by the change in the default preemption model on s390 from NONE to LAZY. That seems to have exposed the issue by allowing some forward progress to be made while the actual system timer tick is still starved, preventing jiffies from increasing or the task context from making much progress towards
max_iterations.
Quoted 6 lines
Fixes 201ceb94aa1d ("kunit: irq: Ensure timer doesn't fire too frequently")Signed-off-by Eric Biggers <[email protected]>---
This patch is targeting libcrypto-next
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-next
- Eric