Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 13 Nov 2019 10:36:49 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Juri Lelli <juri.lelli@redhat.com>
Cc:     mingo@redhat.com, glenn@aurora.tech, linux-kernel@vger.kernel.org,
        rostedt@goodmis.org, vincent.guittot@linaro.org,
        dietmar.eggemann@arm.com, tglx@linutronix.de,
        luca.abeni@santannapisa.it, c.scordino@evidence.eu.com,
        tommaso.cucinotta@santannapisa.it, bristot@redhat.com
Subject: Re: [PATCH 2/2] sched/deadline: Temporary copy static parameters to
 boosted non-DEADLINE entities
Message-ID: <20191113093649.GI4131@hirez.programming.kicks-ass.net>
References: <20191112075056.19971-1-juri.lelli@redhat.com>
 <20191112075056.19971-3-juri.lelli@redhat.com>
 <20191112105130.GZ4131@hirez.programming.kicks-ass.net>
 <20191113092241.GB29273@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191113092241.GB29273@localhost.localdomain>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.