We calculate difference between two readings of a clock to see how
much time has elapsed. Part of the time between rq_clock(rq) -
dl_se->deadline can indeed be accounted for by reading a different
clock
(i.e., rq_clock_task()) if the task was running during the period.
And that is how dl_se->runti
On Wed, 2 Jul 2014 19:44:04 -0400
Zhihui Zhang wrote:
> My point is that rq_clock(rq) - dl_se->deadline is already part of
> dl_se->runtime, which is decremented before calling dl_runtime_exceeded().
But, we decrement dl_se->runtime looking at rq_clock_task(rq), that is
in general <= rq_clock(rq
On Tue, 1 Jul 2014 15:08:16 +0200
Peter Zijlstra wrote:
> On Sun, Jun 29, 2014 at 09:26:10PM -0400, Zhihui Zhang wrote:
> > Unless we want to double-penalize an overrun task, the time after the
> > deadline
> > and before the current time is already accounted in the negative
> > dl_se->runtime
On Sun, Jun 29, 2014 at 09:26:10PM -0400, Zhihui Zhang wrote:
> Unless we want to double-penalize an overrun task, the time after the deadline
> and before the current time is already accounted in the negative
> dl_se->runtime
> value. So we can leave it as is in the case of dmiss && rorun.
Juri?
Unless we want to double-penalize an overrun task, the time after the deadline
and before the current time is already accounted in the negative dl_se->runtime
value. So we can leave it as is in the case of dmiss && rorun.
Signed-off-by: Zhihui Zhang
---
kernel/sched/deadline.c | 6 ++
1 file
5 matches
Mail list logo