Messages in this thread | | | Date | Mon, 23 Apr 2012 22:25:03 +0100 | From | Tommaso Cucinotta <> | Subject | Re: [PATCH 05/16] sched: SCHED_DEADLINE policy implementation. |
| |
Il 23/04/2012 11:37, Juri Lelli ha scritto: > On 04/23/2012 12:31 PM, Peter Zijlstra wrote: >> On Fri, 2012-04-06 at 09:14 +0200, Juri Lelli wrote: >>> + dl_se->deadline = rq->clock + dl_se->dl_deadline; >> >> You might want to use rq->clock_task, this clock excludes times spend in >> hardirq context and steal-time (when paravirt). >> >> Then again, it might not want to use that.. but its something you might >> want to consider and make explicit by means of a comment. > > Yes, I planned a consistency check for the use of clock/clock_task > throughout the code, but it seems I then forgot it. > Planned for the next iteration :-).
unless I'm mistaken, there are 3 repetitions of this block in 05/16:
+ dl_se->deadline = rq->clock + dl_se->dl_deadline; + dl_se->runtime = dl_se->dl_runtime;
perhaps enclosing them into a function (e.g., reset_from_now() or similar) may help to keep consistency...
Another thing: I cannot get the real difference between rq->clock and rq->task_clock. If task_clock is a kind of CLOCK_MONOTONIC thing that increases only when the task (or any task) is scheduled, then you don't want to use that here. Here you need to set the new ->deadline to an absolute time, so I guess the regular rq->clock is what you need, isn't it ?
Hope I didn't say too much nonsense.
T.
-- Tommaso Cucinotta, Computer Engineering PhD, Researcher ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy Tel +39 050 882 024, Fax +39 050 882 003 http://retis.sssup.it/people/tommaso
| |