On Thu, 23 Jun 2005 10:03, Con Kolivas wrote:
> About the only scenario I can envision a high priority task being delayed
> with the code as it currently is in 2.6.12-mm1 is with a high priority task
> being on the expired array and a low priority task being delayed on the
> active array. This still should not create large latencies unless array
> swapping is significantly delayed. I considered adding a check for this
> originally but it seemed to be unnecessary extra complexity since an
> expired task by design is expected to be delayed more anyway.
BTW if this is an issue it would only require a patch like this.
Cheers,
Con
Index: linux-2.6.12-mm1/kernel/sched.c
===================================================================
--- linux-2.6.12-mm1.orig/kernel/sched.c 2005-06-23 00:10:22.000000000 +1000
+++ linux-2.6.12-mm1/kernel/sched.c 2005-06-23 23:19:35.000000000 +1000
@@ -2784,7 +2784,8 @@ static inline int dependent_sleeper(int
ret = 1;
} else
if (((smt_curr->time_slice * (100 - sd->per_cpu_gain) /
- 100) > task_timeslice(p)))
+ 100) > task_timeslice(p)) &&
+ p->static_prio <= this_rq->best_expired_prio)
ret = 1;
check_smt_task:
@@ -2807,7 +2808,8 @@ check_smt_task:
resched_task(smt_curr);
} else {
if ((p->time_slice * (100 - sd->per_cpu_gain) / 100) >
- task_timeslice(smt_curr))
+ task_timeslice(smt_curr) &&
+ smt_curr->static_prio <= smt_rq->best_expired_prio)
resched_task(smt_curr);
else
wakeup_busy_runqueue(smt_rq);
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
