Re: [PATCH v5 03/29] sched/deadline: Do not admit bandwidth for parameters that are kept

[Mathieu Desnoyers]

On 2026-11-09 07:42, Juri Lelli wrote:
[...]
> >   kernel/sched/syscalls.c | 7 ++++++-
> >   1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c
> > index 0e8b5c7324f6..894f93a80d5d 100644
> > --- a/kernel/sched/syscalls.c
> > +++ b/kernel/sched/syscalls.c
> > @@ -690,8 +690,13 @@ int __sched_setscheduler(struct task_struct *p,
> >   	 * of a SCHED_DEADLINE task) we need to check if enough bandwidth
> >   	 * is available. Keep this check last. If a later check failed,
> >   	 * nothing would give back the bandwidth it reserves.
> > +	 *
> > +	 * With SCHED_FLAG_KEEP_PARAMS, the task keeps its parameters, so
> > +	 * there is nothing to admit. The parameters in attr may also be
> > +	 * stale: sys_sched_setattr() read them from the task without a lock.
>
> However I had to wonder what usecase would still make sense for a
> KEEP_PARAMS call on a SCHED_DEADLINE task, I would say a !DL params
> change (UCLAMP for example) for a (at the moment) DEADLINE task that
> might become !DEADLINE in the future? Maybe we could add this to the
> comment.

Yes, that is the case I see too. The deadline class does not set
uclamp_enabled, but __setscheduler_uclamp() stores the clamps for any
class. I will extend the comment in the next version:

         * With SCHED_FLAG_KEEP_PARAMS, the task keeps its parameters, so
         * there is nothing to admit. Such a call changes other attributes,
         * such as the utilization clamps. A deadline task does not use its
         * clamps, but keeps them for when it leaves the class. The
         * parameters in attr may also be stale: sys_sched_setattr() read
         * them from the task without a lock.

Thanks for the review!

Mathieu



--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com