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

[luca abeni <luca.abeni@santannapisa.it>]

Hi Marcel,

On Sat, 03 May 2025 15:14:50 +0200
Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> wrote:
[...]
> > Marcel, are your tests on a multi-core machine with global
> > scheduling? If yes, we should check if the taskset is schedulable.  
> 
> Yes, as previously mentioned, we run all our tests on multi-core
> machines. Not sure though, what exactly you are referring to by
> "global scheduling". Do you mean using Global Earliest Deadline First
> (GEDF)? I guess that is what SCHED_DEADLINE is using, not?

Yes, I meant global EDF (and, yes, this is what SCHED_DEADLINE uses
unless you play with isolated cpusets or affinities).

One potential issue is that global EDF does not guarantee the
hard respect of deadlines, but only provides guarantees about bounded
tardiness. Then, in practice many tasksets run without missing
deadlines even if they are not guaranteed to be schedulable (the hard
schedulability tests are very pessimistic).

When using GRUB (actually, m-GRUB), the runtimes of the tasks are
increased to reclaim unreserved CPU time, and this increases the
probability to miss deadlines. m-GRUB guarantees that all deadlines are
respected only if some hard schedulability tests (more complex than the
admission control policy used by SCHED_DEADLINE) are respected.
This paper provides more details about such schedulability tests:
https://hal.science/hal-01286130/document
(see Section 4.2)

I see that in another email you describe the taskset you are using...
I'll try to have a look at it to check if the issue you are seeing is
related to what I mention above, or if there is some other issue.


			Luca

> 
> Concerning the taskset being schedulable, it is not that it does not
> schedule at all. Remember, from hundreds of millions of test runs
> over the course of a full week where we usually see absolutely zero
> deadline misses (without reclaim), we see 43 million deadline misses
> (with that one rogue process set to reclaim) on NUC and 600 thousand
> on ROCK5B (which also has double the CPU cores).
> 
> Please let me know if you need any further details which may help
> figuring out what exactly is going on.
> 
> > 			Thanks,  
> 
> Thank you!
> 
> > 				Luca  
> 
> Cheers
> 
> Marcel