All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: "K.R. Foley" <kr@cybsft.com>, Ingo Molnar <mingo@elte.hu>,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable
Date: Wed, 27 Jul 2005 13:25:37 -0400	[thread overview]
Message-ID: <1122485137.29823.109.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.OSF.4.05.10507271852030.3210-100000@da410.phys.au.dk>

On Wed, 2005-07-27 at 19:01 +0200, Esben Nielsen wrote:
> 
> What for? Why can't you use FIFO at the same priorities for some of your
> tasks? I pretty much quess you have a very few tasks which have some high
> requirements. The rest of you "RT" task could easily share the lowest RT
> priority. FIFO would also be more effective as you will have context
> switches.
> 
> This about multiple priorities probably comes from an ordering of tasks:
> You have a lot of task. You have a feeling about which one ought to be
> more important than the other. Thus you end of with an ordered list of
> tasks. BUT when you boil it down to what RT is all about, namely
> meeting your deadlines, it doesn't matter after the 5-10 priorities
> because the 5-10 priorities have introduced a lot of jitter to the rest
> of the tasks anyway. You can just as well just put them at the same
> priority.

Nope, I wouldn't agree with you here.  If you have tasks that will run
periodically, at different frequencies, you need to order them. And each
task would probably need a different priority. FIFO is very dangerous
since it doesn't release a task until that task voluntarily sleeps.

A colleague of mine, well actually the VP of my company of the time,
Doug Locke, gave me a perfect example.  If you have a program that runs
a nuclear power plant that needs to wake up and run 4 seconds every 10
seconds, and on that same computer you have a program running a washing
machine that needs to wake up every 3 seconds and run for one second
(I'm using seconds just to make the example simple). Which process gets
the higher priority?  The answer is the washing machine.

Rational:  If the power plant was higher priority, the washing machine
would fail almost every time, since the power plant program would run
for 4 seconds, and since the cycle of the washing machine is 3 seconds,
it would fail everytime the nuclear power plant program ran.  Now if you
have the washing machine run in it's cycle, the nuclear power plant can
easily make the 4 seconds ever 10 seconds, even when it is interrupted
by the washing machine.

Doug also mentioned that you really want to have every task with a
different priority, so it makes sense to have a lot of priorities.  I
can't remember why he said this, but I'm sure you and I can find out by
searching through his papers.

-- Steve




  reply	other threads:[~2005-07-27 17:25 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-27 14:13 [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable Steven Rostedt
2005-07-27 14:17 ` Ingo Molnar
2005-07-27 14:26   ` Steven Rostedt
2005-07-27 14:33     ` Ingo Molnar
2005-07-27 14:47       ` [PATCH] safty check of MAX_RT_PRIO >= MAX_USER_RT_PRIO Steven Rostedt
2005-07-27 15:05         ` Steven Rostedt
2005-07-27 18:52         ` Ingo Molnar
2005-07-27 14:53       ` [RFC][PATCH] Make MAX_RT_PRIO and MAX_USER_RT_PRIO configurable Esben Nielsen
2005-07-27 15:02         ` Steven Rostedt
2005-07-27 16:09         ` K.R. Foley
2005-07-27 17:01           ` Esben Nielsen
2005-07-27 17:25             ` Steven Rostedt [this message]
2005-07-27 21:32               ` Esben Nielsen
2005-07-28 12:17                 ` Steven Rostedt
2005-07-28  7:22               ` Ingo Molnar
2005-07-28 11:53                 ` Steven Rostedt
2005-07-27 17:42             ` K.R. Foley
2005-07-28  9:59               ` Esben Nielsen
2005-07-27 14:28   ` Steven Rostedt
2005-07-27 14:38     ` Ingo Molnar
2005-07-27 14:46       ` Steven Rostedt
2005-07-28  7:33         ` Ingo Molnar
2005-07-28  1:42   ` Matt Mackall
2005-07-28  1:00 ` Daniel Walker
2005-07-28  1:20   ` Lee Revell
2005-07-28  1:26     ` Steven Rostedt
2005-07-28  1:25   ` Steven Rostedt
2005-07-28  3:06     ` Steven Rostedt
2005-07-28  3:32       ` Steven Rostedt
2005-07-28  3:45         ` Steven Rostedt
2005-07-28  3:51           ` Nick Piggin
2005-07-28 11:43             ` [PATCH] speed up on find_first_bit for i386 (let compiler do the work) Steven Rostedt
2005-07-28 12:45               ` Steven Rostedt
2005-07-28 15:31                 ` Linus Torvalds
2005-07-28 15:30               ` Linus Torvalds
2005-07-28 15:47                 ` Steven Rostedt
2005-07-28 16:34                   ` Maciej W. Rozycki
2005-07-28 16:57                     ` Steven Rostedt
2005-07-28 17:25                       ` Linus Torvalds
2005-07-29 10:03                         ` David Woodhouse
2005-07-29 14:41                           ` Maciej W. Rozycki
2005-07-29 16:23                           ` Linus Torvalds
2005-07-29 14:39                         ` Maciej W. Rozycki
2005-07-29 16:29                           ` Linus Torvalds
2005-07-29 17:14                             ` Maciej W. Rozycki
2005-07-28 17:17                     ` Linus Torvalds
2005-07-29 15:09                       ` Maciej W. Rozycki
2005-07-28 18:25                     ` Steven Rostedt
2005-07-28 18:56                       ` Linus Torvalds
2005-07-28 17:52               ` Mitchell Blank Jr

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=1122485137.29823.109.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=akpm@osdl.org \
    --cc=kr@cybsft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=simlo@phys.au.dk \
    --cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.