linux-kernel - Re: [PATCH] sched/deadline: Always calculate end of period on sched

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: <20160215112201.774a2c0d@gandalf.local.home>
Date:	Mon, 15 Feb 2016 11:22:01 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Juri Lelli <juri.lelli@....com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Juri Lelli <juri.lelli@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	Clark Williams <williams@...hat.com>,
	Daniel Bristot de Oliveira <bristot@...hat.com>,
	John Kacur <jkacur@...hat.com>
Subject: Re: [PATCH] sched/deadline: Always calculate end of period on
 sched_yield()

On Mon, 15 Feb 2016 10:18:24 +0000
Juri Lelli <juri.lelli@....com> wrote:

> > Signed-off-by: Steven Rostedt <rostedt@...dmis.org>
> > ---
> > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> > index cd64c979d0e1..1dd180cda574 100644
> > --- a/kernel/sched/deadline.c
> > +++ b/kernel/sched/deadline.c
> > @@ -735,7 +735,7 @@ static void update_curr_dl(struct rq *rq)
> >  	 * approach need further study.
> >  	 */
> >  	delta_exec = rq_clock_task(rq) - curr->se.exec_start;
> > -	if (unlikely((s64)delta_exec <= 0))
> > +	if (unlikely((s64)delta_exec <= 0 && !dl_se->dl_yielded))
> >  		return;
> >  
> 
> This looks good to me. Do you think we could also skip some of the
> following updates/accounting in this case? Not sure we win anything by
> doing that, though.
>

Well, I would say we get this patch in first and think about other
updates second. This fixes one bug, might as well pull it in.

I'm now looking into a second bug. I'm getting:

 RT throttling activated

and

 DL replenish lagged to much

messages, back to back, when I'm only using 50% of the band width.
Looks to be a leak of how much is being used. The big issue here is
that these messages kill the test due to the latency caused to perform
the printk(). After the messages are splatted out (they only print once
per boot), the tests run fine again. IOW, there seems to be no real
issue of something doing too much bandwidth.

I get this with or without this current patch.

-- Steve