Messages in this thread | | | Date | Sun, 21 Oct 2007 11:35:56 +0200 | From | "Dmitry Adamushko" <> | Subject | Re: [patch 6/8] pull RT tasks |
| |
Hi Steven,
> When a pull RT is initiated, all overloaded runqueues are examined for > a RT task that is higher in prio than the highest prio task queued on the > target runqueue. If another runqueue holds a RT task that is of higher > prio than the highest prio task on the target runqueue is found it is pulled > to the target runqueue.
I think, 2 things should be accomplished here :
(1) be sure to pull the _highest_ prio task ;
i.e. the _highest_ prio task amongst all runnable (but not running) RT tasks across all the run-queues which is capable of running on this_cpu ;
(2) don't pull more than 1 task at once.
that said, just pull the highest prio task and run it.
---
why (2)? Just to avoid situations when tasks are being pulled/pushed back and forth between run-queues.
Let's say we have 4 cpu system:
0: task(10) , task(92) 1: task(10), task(91) 2: task(10), task(90) 3: task(10)
when task(10) on cpu#3 is inactive, we pull task(92), task(91), task(90) and then run task(90)... in the mean time, some of cpu[0..2] becomes inactive and pull task(91) and task(92) back and run them... that may repeat again and again depending on when/how long task(10) run on their corresponding cpus...
so it seems to me that the more optimal behavior would be "don't pull more than you can run at the moment -- that's 1".
to this goal, something like find_lock_highest_rq() would be necessary.
and I guess, {get,put}_task_struct() should be used in pull_rt_task() for the 'next' in a similar way as it's done in push_rt_task() .
> > [ ... ] >
-- Best regards, Dmitry Adamushko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |