Ciao,
while studying how real-time tasks (i.e. SCHED_FIFO or SCHED_RR) are
implemented on SMP systems with respect to preemption of lower priority
tasks, I came to the following question:
On uni-processor (UP) systems higher priority tasks are guaranteed to
preempt lower priority ones as soon as they become runnable. Now I am
wondering what happens on SMP systems as ideally for example once a RT
task which has a higher priority than any of the currently executing
tasks on the different CPUs becomes runnable it should also be
immediately scheduled on the CPU with the lowest priority currently
executing task. So, in terms of real-time, it should be guaranteed that
at any moment the set of runnable tasks with the highest priorities are
actually running on the available CPUs.
Now, while studying the Linux kernel (precisely version 2.6.24.4 with
Ingo Molnar's RT patch version 2.6.24.4-rt4 applied) it seemed to me as
if the kernel maintains a separate run queue for each of the available
CPUs and would anyway put a RT task which becomes (again) runnable on
the run queue of the CPU with the lowest priority currently executing
task, but I could not find anything which would make sure that a
rescheduling takes place (e.g. by triggering an IPI) in case the awaking
task has a higher priority and the current CPU is different from the
selected one (on whose run queue it has put the awaking task).
Now, first of all I would like to ask if my observation is correct?
If yes, I am wondering if this problem has in the meanwhile been tackled
with, is currently under investigation, is gonna be tackled with in the
(near) future, is considered as being non resolvable (e.g. without
compromising the overall throughput of the system too heavily), or ...
something else?
Regards,
Wolfgang
P.S.: similarly to the above example, in case a RT task blocks, to me
it seems as if the next task is gonna be taken from the run queue
of the current CPU without considering that another CPU might have
a higher priority runnable task in its run queue.
--
To unsubscribe from this list: send the line "unsubscribe linux-smp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
