Re: SCHED_DEADLINE tasks missing their deadline with SCHED_FLAG_RECLAIM jobs in the mix (using GRUB)

Juri Lelli
2025-06-25T09:30:46Z

On 24/06/25 17:00, luca abeni wrote:
> On Tue, 24 Jun 2025 14:59:13 +0200
> Juri Lelli <juri.lelli@redhat.com> wrote:
>
> > Hello again,
> >
> > On 24/06/25 09:49, Juri Lelli wrote:
> >
> > ...
> >
> > > The following seem to at least cure the problem after boot. Things
> > > are still broken after cpusets creation. Moving to look into that,
> > > but wanted to share where I am so that we don't duplicate work.
> >
> > I ended up with two additional patches that seem to make things a
> > little better at my end. You can find them at
> >
> > https://github.com/jlelli/linux/tree/upstream/fix-grub
> >
> > Marcel, Luca, can you please give them a quick try to check if they do
> > any good?
>
> I applied your 3 patches to the master branch of linux.git, and they
> indeed seems to fix the issue!
>
> Now, I need to understand how they relate to
> 5f6bd380c7bdbe10f7b4e8ddcceed60ce0714c6d :)
>
> One small issue: after applying your patches, I get this WARN at boot
> time:
> [ 0.384481] ------------[ cut here ]------------
> [ 0.385384] WARNING: CPU: 0 PID: 1 at kernel/sched/deadline.c:265 task_non_contending+0x24d/0x3b0
> [ 0.385384] Modules linked in:
> [ 0.385384] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc2-00234-ge35a18896578 #42 PREEMPT(voluntary)
> [ 0.385384] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> [ 0.385384] RIP: 0010:task_non_contending+0x24d/0x3b0
> [ 0.385384] Code: 59 49 00 e9 7a fe ff ff 48 8b 53 30 f6 43 53 10 0f 85 4c ff ff ff 48 8b 85 c8 08 00 00 48 29 d0 48 89 85 c8 08 00 00 73 0f 90 <0f> 0b 90 48 c7 85 c8 08 00 00 00 00 00 00 48 63 95 28 0b 00 00 48
> [ 0.385384] RSP: 0000:ffffb52300013c08 EFLAGS: 00010093
> [ 0.385384] RAX: ffffffffffff3334 RBX: ffff979ffe8292b0 RCX: 0000000000000001
> [ 0.385384] RDX: 000000000000cccc RSI: 0000000002faf080 RDI: ffff979ffe8292b0
> [ 0.385384] RBP: ffff979ffe8289c0 R08: 0000000000000001 R09: 00000000000002a5
> [ 0.385384] R10: 0000000000000000 R11: 0000000000000001 R12: ffffffffffe0ab69
> [ 0.385384] R13: ffff979ffe828a40 R14: 0000000000000009 R15: ffff979ffe8289c0
> [ 0.385384] FS: 0000000000000000(0000) GS:ffff97a05f709000(0000) knlGS:0000000000000000
> [ 0.385384] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.385384] CR2: ffff979fdec01000 CR3: 000000001e030000 CR4: 00000000000006f0
> [ 0.385384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 0.385384] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 0.385384] Call Trace:
> [ 0.385384] <TASK>
> [ 0.385384] dl_server_stop+0x21/0x40
> [ 0.385384] dequeue_entities+0x604/0x900
> [ 0.385384] dequeue_task_fair+0x85/0x190
> [ 0.385384] ? update_rq_clock+0x6c/0x110
> [ 0.385384] __schedule+0x1f0/0xee0
> [ 0.385384] schedule+0x22/0xd0
> [ 0.385384] schedule_timeout+0xf4/0x100
> [ 0.385384] __wait_for_common+0x97/0x180
> [ 0.385384] ? __pfx_schedule_timeout+0x10/0x10
> [ 0.385384] ? __pfx_devtmpfsd+0x10/0x10
> [ 0.385384] wait_for_completion_killable+0x1f/0x40
> [ 0.385384] __kthread_create_on_node+0xe7/0x150
> [ 0.385384] kthread_create_on_node+0x4f/0x70
> [ 0.385384] ? register_filesystem+0x97/0xc0
> [ 0.385384] devtmpfs_init+0x115/0x200
> [ 0.385384] driver_init+0x15/0x50
> [ 0.385384] kernel_init_freeable+0xf4/0x2d0
> [ 0.385384] ? __pfx_kernel_init+0x10/0x10
> [ 0.385384] kernel_init+0x15/0x1c0
> [ 0.385384] ret_from_fork+0x80/0xd0
> [ 0.385384] ? __pfx_kernel_init+0x10/0x10
> [ 0.385384] ret_from_fork_asm+0x1a/0x30
> [ 0.385384] </TASK>
> [ 0.385384] ---[ end trace 0000000000000000 ]---

I now see it as well, not sure how I missed it, maybe didn't pay enough
attention. :)

It looks like (at least at my end) it comes from

task_non_contending()
sub_running_bw()
__sub_running_bw()
WARN_ON_ONCE(dl_rq->running_bw > old); /* underflow */

I would guess the later initialization of dl-server is not playing well
wrt running_bw. Will take a look.

BTW, I pushed an additional fixup commmit (forgot some needed locking
here and there, ops :).