public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Patrik Hägglund" <patrik.hagglund@bredband.net>
To: Chris Friesen <cfriesen@nortel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SCHED_RR/SCHED_FIFO and kernel threads?
Date: Fri, 17 Jun 2005 08:38:48 +0200	[thread overview]
Message-ID: <42B26FF8.6090505@bredband.net> (raw)
In-Reply-To: <42B19F65.6000102@nortel.com>

Chris Friesen wrote:

> Patrik Hägglund wrote:
>
>> Kernel threads seems to generally be scheduled in the SCHED_OTHER 
>> class (with the 'migration' thread as an exception).
>
>
> This is on purpose.  The idea is that realtime processes get all the 
> time they request.  If the kernel threads are interrupting the 
> realtime app, then the latency of the realtime app is degraded.

Don't you get the problem with priority inversion? I.e., if you have two 
processes, P1 and P2, scheduled with SCHED_FIFO, where P1 has higer 
priority than P2. Now, if P1 gets blocked and needs some kernel thread 
to execute to get unblocked, then P2 is scheduled before the kernel 
thread, and can execute without any time limit.

That is, you should be much better off if the kernel threads has a 
_high_ priority. Then the execution progress can only be blocked by 
kernel threads, not by user space threads and processes. Or have I 
missed something?

(Besides that, as I see it, SCHED_RR/SCHED_FIFO are scheduling 
abstractions on their own, not necessarily  connected to  "low latency " 
or "realtime".)

  reply	other threads:[~2005-06-17  6:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-16 15:25 SCHED_RR/SCHED_FIFO and kernel threads? Patrik Hägglund
2005-06-16 15:48 ` Chris Friesen
2005-06-17  6:38   ` Patrik Hägglund [this message]
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=42B26FF8.6090505@bredband.net \
    --to=patrik.hagglund@bredband.net \
    --cc=cfriesen@nortel.com \
    --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