linux-kernel - RT task preemtion/scheduling on SMP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4886EA28.4080801@st.com>
Date:	Wed, 23 Jul 2008 10:22:00 +0200
From:	Wolfgang Johann BETZ <wolfgang.betz@...com>
To:	linux-kernel@...r.kernel.org
Cc:	Wolfgang Betz <wolfgang.betz@...com>, mingo@...e.hu
Subject: RT task preemtion/scheduling on SMP

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/