On 4/14/2025 8:20 PM, K Prateek Nayak wrote:
BTW, does anyone already have a test case that produces the lockup issue
with one or two simple programs and some hectic CFS bandwidth settings?
This is your cue to grab a brown paper bag since what I'm about to paste
below is probably lifetime without parole in the RT land but I believe
it gets close to the scenario described by Valentin:
(Based on v6.15-rc1; I haven't yet tested this with Aaron's series yet)
I tried this with Aaron's series [1] and I did not run into any rcu
stalls yet. following are dmesg logs:
[ 122.853909] sched_cfs_period_timer: Started on CPU248
[ 122.853912] sched_cfs_period_timer: Finished on CPU248
[ 123.726232] dumb_ways_to_die: Started on CPU248 with 50000000 loops
[ 123.726574] dumb_ways_to_die: Queuing timer on CPU248
[ 123.726577] dumb_ways_to_die: Waking up RT kthread on CPU248
[ 125.768969] RT kthread: Started on CPU248
[ 125.769050] deadlock_timer: Started on CPU248
# Fair task runs, drops rwlock, is preempted
[ 126.666709] RT kthread: Finished on CPU248
# RT kthread finishes
[ 126.666737] deadlock_timer: Finished on CPU248
# ktimerd function finishes and unblocks replenish
[ 126.666740] sched_cfs_period_timer: Started on CPU248
[ 126.666741] sched_cfs_period_timer: Finished on CPU248
# cfs task runs prctl() to completion and is throttled
[ 126.666762] dumb_ways_to_die: Finished on CPU248 with 50000000 loops
# cfs_bandwidth continues to catch up on slack accumulated
[ 126.851820] sched_cfs_period_timer: Started on CPU248
[ 126.851825] sched_cfs_period_timer: Finished on CPU248
[1] https://lore.kernel.org/all/20250409120746.635476-1-ziqianlu@xxxxxxxxxxxxx/
--
Thanks and Regards,
Prateek
