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: <aFV-HEwOTq0a37ax@jlelli-thinkpadt14gen4.remote.csb>
Date: Fri, 20 Jun 2025 17:28:28 +0200
From: Juri Lelli <juri.lelli@...hat.com>
To: luca abeni <luca.abeni@...tannapisa.it>
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 20/06/25 16:16, luca abeni wrote:
> On Fri, 20 Jun 2025 11:37:45 +0200
> luca abeni <luca.abeni@...tannapisa.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

Is Umax == max_bw from above?

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

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

Thanks!
Juri