From: Wolfgang Johann BETZ <wolfgang.betz@st.com>
To: linux-smp@vger.kernel.org
Cc: Wolfgang Betz <wolfgang.betz@st.com>
Subject: RT task preemption/scheduling on SMP
Date: Mon, 28 Jul 2008 10:26:37 +0200 [thread overview]
Message-ID: <488D82BD.4080003@st.com> (raw)
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.
reply other threads:[~2008-07-28 8:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=488D82BD.4080003@st.com \
--to=wolfgang.betz@st.com \
--cc=linux-smp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).