Re: [PATCH 2/2] sched/deadline: Temporary copy static parameters to boosted non-DEADLINE entities

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Nov 13, 2019 at 10:22:41AM +0100, Juri Lelli wrote:

> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 26e4ffa01e7a..16164b0ba80b 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -4452,9 +4452,11 @@ void rt_mutex_setprio(struct task_struct *p, struct task_struct *pi_task)
> >  		if (!dl_prio(p->normal_prio) ||
> >  		    (pi_task && dl_entity_preempt(&pi_task->dl, &p->dl))) {
> >  			p->dl.dl_boosted = 1;
> > -			queue_flag |= ENQUEUE_REPLENISH;
> > -		} else
> > +			p->dl.deadline = pi_task->dl.deadline;
> > +		} else {
> >  			p->dl.dl_boosted = 0;
> > +			p->dl.deadline = p->dl.normal_deadline;
> > +		}
> >  		p->sched_class = &dl_sched_class;
> >  	} else if (rt_prio(prio)) {
> >  		if (dl_prio(oldprio))

> So, the problem is more related to pi_se->dl_runtime than its deadline.
> Even if we don't replenish at the instant in time when boosting happens,
> the boosted task might still deplete its runtime while being boosted and

I thought we ignored all runtime checks when we were boosted? Yes, that
is all sorts of broken, but IIRC we figured that barring something like
proxy-execution there really wasn't anything sane we could do wrt
bandwidth anyway.

Seeing how proper bandwidth handling would have the boosted task consume
the boostee's budget etc.. And blocking the entire boost chain when it
collectively runs out.