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

[Juri Lelli <juri.lelli@redhat.com>]

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 :).