Perhaps the following is a better patch compare to earlier one.
The p->sleep_type are only for SCHED_NORMAL as well, so we can
bypass them altogether in one shot.
RT task does not participate in interactiveness priority and thus
shouldn't be bothered with timestamp and p->sleep_type manipulation
when task is being put on run queue. Bypass all of the them with
a single if (rt_task) test.
Signed-off-by: Ken Chen <[email protected]>
--- ./kernel/sched.c.orig 2006-11-14 13:29:37.000000000 -0800
+++ ./kernel/sched.c 2006-11-14 14:05:39.000000000 -0800
@@ -938,6 +938,9 @@ static void activate_task(struct task_st
{
unsigned long long now;
+ if (rt_task(p))
+ goto out;
+
now = sched_clock();
#ifdef CONFIG_SMP
if (!local) {
@@ -947,9 +950,7 @@ static void activate_task(struct task_st
+ rq->timestamp_last_tick;
}
#endif
-
- if (!rt_task(p))
- p->prio = recalc_task_prio(p, now);
+ p->prio = recalc_task_prio(p, now);
/*
* This checks to make sure it's not an uninterruptible task
@@ -974,7 +975,7 @@ static void activate_task(struct task_st
}
}
p->timestamp = now;
-
+out:
__activate_task(p, rq);
}
On Tue, 2006-11-14 at 15:55 -0800, Chen, Kenneth W wrote:
> Perhaps the following is a better patch compare to earlier one.
> The p->sleep_type are only for SCHED_NORMAL as well, so we can
> bypass them altogether in one shot.
>
>
>
>
> RT task does not participate in interactiveness priority and thus
> shouldn't be bothered with timestamp and p->sleep_type manipulation
> when task is being put on run queue. Bypass all of the them with
> a single if (rt_task) test.
Personally, I think it's best to leave it as it is. With that change,
if someone changes policy while the task is waiting to get cpu, it will
be requeued, and the on-runqueue bonus logic will then end up using
wildly inaccurate information. Unlikely, true (hmm, what about PI...
afaik, works both ways), but from the correctness standpoint, I think
the information we use in heuristics should always be kept as accurate
as possible.
If you want to shave cycles, IMHO the better investment would be to get
rid of the division in schedule().
-Mike
On Wed, 2006-11-15 at 08:00 +0100, Mike Galbraith wrote:
> Personally, I think it's best to leave it as it is. With that change,
> if someone changes policy while the task is waiting to get cpu, it will
> be requeued, and the on-runqueue bonus logic will then end up using
> wildly inaccurate information.
Bah, that's inverted. interactive_sleep() will never be true after a
rt->non-rt policy change while enqueued with your change, so on-runqueue
bonus will be disabled where it otherwise might have been enabled. Not
terribly interesting in any case given the likelihood, but still...
-Mike