Messages in this thread | | | Subject | Re: [RFC][PATCH 05/22] sched: SCHED_DEADLINE policy implementation | From | Raistlin <> | Date | Thu, 11 Nov 2010 19:33:08 +0100 |
| |
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@ekiga.net / dario.faggioli@jabber.org [unhandled content-type:application/pgp-signature] | |