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

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20191113094439.GC29273@localhost.localdomain>
Date:   Wed, 13 Nov 2019 10:44:39 +0100
From:   Juri Lelli <juri.lelli@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     mingo@...hat.com, glenn@...ora.tech, linux-kernel@...r.kernel.org,
        rostedt@...dmis.org, vincent.guittot@...aro.org,
        dietmar.eggemann@....com, tglx@...utronix.de,
        luca.abeni@...tannapisa.it, c.scordino@...dence.eu.com,
        tommaso.cucinotta@...tannapisa.it, bristot@...hat.com
Subject: Re: [PATCH 2/2] sched/deadline: Temporary copy static parameters to
 boosted non-DEADLINE entities

On 13/11/19 10:36, Peter Zijlstra wrote:
> 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

We don't throttle and replenish instantly when runtime is depleted, but
we still account runtime. See update_curr_dl(), dl_runtime_exceeded()
and if(unlikely(dl_se->dl_boosted ...) case.

Mmm, maybe we should stop accounting as well and only postpone
deadlines, is this what you had in mind?

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

Yep, this is how it should eventually all work.