From: "Greg Chesson" <greg@xtp.engr.sgi.com>
To: nigel@aa5b.engr.sgi.com (Nigel Gamble), dm@sgi.com
Cc: linux@aa5b.engr.sgi.com
Subject: Re: Linux: the next step
Date: Tue, 13 Aug 1996 09:45:44 -0700 [thread overview]
Message-ID: <9608130945.ZM7238@xtp.engr.sgi.com> (raw)
In-Reply-To: nigel@aa5b (Nigel Gamble) "Re: Linux: the next step" (Aug 13, 8:36am)
The new real-time facilities in Irix (Nawaf's scheduler) are superior to what
has been available before in any Unix-like system that I know of. There are
two areas of shortfall, but these are probably unavoidable given the design and
its operating environment:
1. priority-based scheduling is often a poor substitute for deadline
scheduling, although it is useful for many rt applications.
2. once a process gets scheduled via the rt facility, if it does any
system calls you get Irix system call performance. Sometimes this
will be an issue (by limiting the number of syscalls and rt apps),
and other times it will not be so important.
I believe that efforts to incorporate hard real-time scheduling into a
full-function OS will satisfy the large majority of customers who have
real-time applications. These customers do not want to run on the bare iron -
they want their real-time and they want their OS also.
The Linux-based hack that Larry described is indeed elegant - I had a look at
the paper. However, if that hack were enough to support a wide range of
real-time applications I think system hacks would have implemented it a long
time ago.
g
WARNING: multiple messages have this Message-ID (diff)
From: "Greg Chesson" <greg@xtp.engr.sgi.com>
To: Nigel Gamble <nigel@aa5b.engr.sgi.com>, dm@sgi.com
Cc: linux@aa5b.engr.sgi.com
Subject: Re: Linux: the next step
Date: Tue, 13 Aug 1996 09:45:44 -0700 [thread overview]
Message-ID: <9608130945.ZM7238@xtp.engr.sgi.com> (raw)
Message-ID: <19960813164544.W9jcDwU_ret9k8aXJiNOJYx65kTXxBSiTV1Q837YLRg@z> (raw)
In-Reply-To: nigel@aa5b (Nigel Gamble) "Re: Linux: the next step" (Aug 13, 8:36am)
The new real-time facilities in Irix (Nawaf's scheduler) are superior to what
has been available before in any Unix-like system that I know of. There are
two areas of shortfall, but these are probably unavoidable given the design and
its operating environment:
1. priority-based scheduling is often a poor substitute for deadline
scheduling, although it is useful for many rt applications.
2. once a process gets scheduled via the rt facility, if it does any
system calls you get Irix system call performance. Sometimes this
will be an issue (by limiting the number of syscalls and rt apps),
and other times it will not be so important.
I believe that efforts to incorporate hard real-time scheduling into a
full-function OS will satisfy the large majority of customers who have
real-time applications. These customers do not want to run on the bare iron -
they want their real-time and they want their OS also.
The Linux-based hack that Larry described is indeed elegant - I had a look at
the paper. However, if that hack were enough to support a wide range of
real-time applications I think system hacks would have implemented it a long
time ago.
g
next prev parent reply other threads:[~1996-08-13 16:46 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-08-12 21:49 Linux: the next step Larry McVoy
1996-08-12 21:49 ` Larry McVoy
1996-08-12 22:59 ` Nigel Gamble
1996-08-12 22:59 ` Nigel Gamble
1996-08-12 23:31 ` Bob English
1996-08-12 23:31 ` Bob English
1996-08-13 11:45 ` David S. Miller
1996-08-13 11:45 ` David S. Miller
1996-08-13 15:36 ` Nigel Gamble
1996-08-13 16:45 ` Greg Chesson [this message]
1996-08-13 16:45 ` Greg Chesson
-- strict thread matches above, loose matches on Subject: below --
1996-08-12 21:20 Steve Alexander
1996-08-12 21:20 ` Steve Alexander
[not found] ` <sca@refugee.engr.sgi.com>
1996-08-12 21:35 ` Sandeep Cariapa
1996-08-12 21:39 ` John E. Schimmel
1996-08-12 21:39 ` John E. Schimmel
1996-08-12 21:18 Steve Alexander
1996-08-12 21:18 ` Steve Alexander
1996-08-12 21:24 ` Bob English
1996-08-12 21:24 ` Bob English
1996-08-12 21:09 Larry McVoy
1996-08-12 20:32 Steve Alexander
1996-08-12 20:32 ` Steve Alexander
1996-08-12 20:52 ` Bob English
1996-08-12 20:52 ` Bob English
1996-08-03 1:11 Larry McVoy
1996-07-31 0:48 Ariel Faigon
1996-08-02 15:37 ` Alistair Lambie
1996-08-02 23:07 ` Nigel Gamble
1996-08-02 23:54 ` David S. Miller
1996-08-03 0:12 ` Alistair Lambie
1996-08-03 0:12 ` Alistair Lambie
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=9608130945.ZM7238@xtp.engr.sgi.com \
--to=greg@xtp.engr.sgi.com \
--cc=dm@sgi.com \
--cc=linux@aa5b.engr.sgi.com \
--cc=nigel@aa5b.engr.sgi.com \
/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