linux-kernel - Re: [RFC][PATCH 05/22] sched: 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]

Date:	Thu, 11 Nov 2010 19:33:08 +0100
From:	Raistlin <raistlin@...ux.it>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Chris Friesen <cfriesen@...tel.com>, oleg@...hat.com,
	Frederic Weisbecker <fweisbec@...il.com>,
	Darren Hart <darren@...art.com>,
	Johan Eker <johan.eker@...csson.com>,
	"p.faure" <p.faure@...tech.ch>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Claudio Scordino <claudio@...dence.eu.com>,
	michael trimarchi <trimarchi@...is.sssup.it>,
	Fabio Checconi <fabio@...dalf.sssup.it>,
	Tommaso Cucinotta <cucinotta@...up.it>,
	Juri Lelli <juri.lelli@...il.com>,
	Nicola Manica <nicola.manica@...i.unitn.it>,
	Luca Abeni <luca.abeni@...tn.it>,
	Dhaval Giani <dhaval@...is.sssup.it>,
	Harald Gustafsson <hgu1972@...il.com>,
	paulmck <paulmck@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH 05/22] sched: SCHED_DEADLINE policy implementation

On Thu, 2010-11-11 at 15:17 +0100, Peter Zijlstra wrote:
> > +       dl_se->runtime -= delta_exec;
> > +       if (dl_runtime_exceeded(rq, dl_se)) {
> > +               __dequeue_task_dl(rq, curr, 0);
> > +               if (likely(start_dl_timer(dl_se)))
> > +                       dl_se->dl_throttled = 1;
> > +               else
> > +                       enqueue_task_dl(rq, curr, ENQUEUE_REPLENISH);
> > +
> > +               resched_task(curr);
> > +       }
> > +} 
> 
> So you keep the current task in the rb-tree? 
>
Yes, I do.

> If you remove the current
> task from the tree you don't have to do the whole dequeue/enqueue thing.
> Then again, I guess it only really matters once you push the deadline,
> which shouldn't be that often.
> 
I'm not sure. The likelihood of runtime overrun/deadline pushing depends
on many things, and might happen even if nothing is going bad... Might
be wanted actually!

Suppose you have some sporadic task of some sort with computation ~10ms
and (minimum) interarrival time of jobs of 100ms. Moreover, I want it to
be able to react with a latency in the order of 100us. If I give it
10ms/100ms (or maybe 12ms/100ms, or whatever overprovisioning is
considered enough to be safe), and an instance arrives as soon as the it
has been throttled I may have to wait for 90ms (88, ?).
Thus, I give it 10us/100us, which means it won't stay throttled for more
tha 90us, but also that it's runtime will be exhausted (and it's
deadline pushed away) 1000 times for a typical instance!

Forgive me for the stupid example... What I was trying to point out is
that, especially considering we don't (want to!) have rock solid WCET
analysis, too much bias toward the case were the scheduling parameters
perfectly matches the applications' ones would not be as much
preferable.

For this reasons, I structured the code this way, and it seems to me
that keeping current out the the tree would complicate the code quite a
bit, but I'm also sure it's doable if you really think it is needed.
Just let me know... :-)

> Also, you might want to put a conditional around that resched, no point
> rescheduling if you're still the leftmost task.
> 
Right. This should be done, indeed.

Thanks,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://blog.linux.it/raistlin / raistlin@...ga.net /
dario.faggioli@...ber.org

Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)