From: "Patrik Hägglund" <patrik.hagglund@bredband.net>
To: linux-kernel@vger.kernel.org
Subject: SCHED_RR/SCHED_FIFO and kernel threads?
Date: Thu, 16 Jun 2005 17:25:51 +0200 [thread overview]
Message-ID: <42B199FF.5010705@bredband.net> (raw)
Hi all,
When I use 2.6 kernels (2.6.11) and run processes whith SCHED_RR or
SCHED_FIFO scheduling, kernel activity - in the form of kernel threads -
gets starved. Googling gave me this thread:
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.1/0182.html, which
discuss the topic brifely.
As I remember it, using a 2.4 (or 2.2?) kernel it was possible to run
processes using SCHED_RR/SCHED_FIFO scheduling classes (as defined by
the Process Scheduling option in POSIX), at different priorities,
whitout starving console input/output. For example, in one virtual
terminal I stared a "supervisor" shell with SCHED_FIFO at priority 20,
and then the job tasks I wanted to "run" in other virtual terminals, now
still with SCHED_FIFO, but with lower priorities. If the job tasks
dead-locked or ran into infinite loops, I just switched to the
"supervisor" shell and killed the job tasks. I think I also - as an
alternative - started the whole X server in "supervisor mode". I this
way, I was able to get deterministic scheduling between tasks, and was
still able to avoid locking the machine when things went wrong.
However, using 2.6 kernels the "supervisor mode" doesn't work anymore.
Using virtual terminals at the console, I'm unable to switch to another
VT (using alt-F2), or switch window focus in X.
Kernel threads seems to generally be scheduled in the SCHED_OTHER class
(with the 'migration' thread as an exception).
As I see it, "kernel activity" shall not be starved by user-space
processes. Therefore, I was very suprised by this behaviour when I saw
it in 2.6.11.
Can someone explain how this is supposed to work? Is this the common
design solution used by other operating systems that use kernel threads
and have SCHED_RR/SCHED_FIFO scheduling (i.e. other POSIX operating
systems with kernel threads)? Was there any discussion about the design
when this migration of kernel acitivity into threads started?
Regards,
Patrik Hägglund
next reply other threads:[~2005-06-16 15:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-16 15:25 Patrik Hägglund [this message]
2005-06-16 15:48 ` SCHED_RR/SCHED_FIFO and kernel threads? Chris Friesen
2005-06-17 6:38 ` Patrik Hägglund
2005-06-17 12:37 ` Steven Rostedt
2005-06-18 8:14 ` Patrik Hägglund
2005-06-21 22:15 ` Patrik Hägglund
2005-06-21 22:18 ` Patrik Hägglund
2005-06-22 0:13 ` Lee Revell
2005-06-16 16:01 ` Lee Revell
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=42B199FF.5010705@bredband.net \
--to=patrik.hagglund@bredband.net \
--cc=linux-kernel@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