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

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

On Fri, 20 Jun 2025 11:37:45 +0200
luca abeni <luca.abeni@santannapisa.it> wrote:
[...]
> > Luca, Vineeth (for the recent introduction of max_bw), maybe we
> > could take a step back and re-check (and maybe and document better
> > :) what each variable is meant to do and how it gets updated?  
> 
> I am not sure about the funny values initially assigned to these
> variables, but I can surely provide some documentation about what
> these variables represent... I am going to look at this and I'll send
> some comments or patches.

So, I had a look tying to to remember the situation... This is my
current understanding:
- the max_bw field should be just the maximum amount of CPU bandwidth we
  want to use with reclaiming... It is rt_runtime_us / rt_period_us; I
  guess it is cached in this field just to avoid computing it every
  time.
  So, max_bw should be updated only when
  /proc/sys/kernel/sched_rt_{runtime,period}_us are written
- the extra_bw field represents an additional amount of CPU bandwidth
  we can reclaim on each core (the original m-GRUB algorithm just
  reclaimed Uinact, the utilization of inactive tasks).
  It is initialized to Umax when no SCHED_DEADLINE tasks exist and
  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?

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?)


			Luca

> 
> 
> 			Luca