linux-kernel - Re: SCHED_DEADLINE tasks missing their deadline with SCHED_FLAG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250624153633.6cb8dde8@nowhere>
Date: Tue, 24 Jun 2025 15:36:33 +0200
From: luca abeni <luca.abeni@...tannapisa.it>
To: Juri Lelli <juri.lelli@...hat.com>
Cc: Marcel Ziswiler <marcel.ziswiler@...ethink.co.uk>,
 <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, "Peter
 Zijlstra" <peterz@...radead.org>, Vineeth Pillai <vineeth@...byteword.org>
Subject: Re: SCHED_DEADLINE tasks missing their deadline with
 SCHED_FLAG_RECLAIM jobs in the mix (using GRUB)

On Fri, 20 Jun 2025 18:52:48 +0200
luca abeni <luca.abeni@...tannapisa.it> wrote:
[...]
> > >   should be decreased by Ui when a task with utilization Ui
> > > becomes SCHED_DEADLINE (and increased by Ui when the
> > > SCHED_DEADLINE task terminates or changes scheduling policy).
> > > Since this value is per_core, Ui is divided by the number of
> > > cores in the root domain... From what you write, I guess extra_bw
> > > is not correctly initialized/updated when a new root domain is
> > > created?    
> > 
> > It looks like so yeah. After boot and when domains are dinamically
> > created. But, I am still not 100%, I only see weird numbers that I
> > struggle to relate with what you say above. :)  
> 
> BTW, when running some tests on different machines I think I found out
> that 6.11 does not exhibit this issue (this needs to be confirmed, I
> am working on reproducing the test with different kernels on the same
> machine)
> 
> If I manage to reproduce this result, I think I can run a bisect to
> the commit introducing the issue (git is telling me that I'll need
> about 15 tests :)
> So, stay tuned...

It took more than I expected, but I think I found the guilty commit...
It seems to be
[5f6bd380c7bdbe10f7b4e8ddcceed60ce0714c6d] sched/rt: Remove default bandwidth control

Starting from this commit, I can reproduce the issue, but if I test the
previous commit (c8a85394cfdb4696b4e2f8a0f3066a1c921af426
sched/core: Fix picking of tasks for core scheduling with DL server)
the issue disappears.

Maybe this information can help in better understanding the problem :)



			Luca

> 
> > > All this information is probably not properly documented...
> > > Should I improve the description in
> > > Documentation/scheduler/sched-deadline.rst or do you prefer some
> > > comments in kernel/sched/deadline.c? (or .h?)    
> > 
> > I think ideally both. sched-deadline.rst should probably contain the
> > whole picture with more information and .c/.h the condendensed
> > version.  
> 
> OK, I'll try to do this in next week
> 
> 
> 			Thanks,
> 				Luca