From: lm@gate1-neteng.engr.sgi.com (Larry McVoy)
To: jes@machine.engr.sgi.com (John E. Schimmel)
Cc: sca@refugee.engr.sgi.com (Steve Alexander),
lm@neteng.engr.sgi.com, nigel@cthulhu.engr.sgi.com,
alambie@wellington.sgi.com, ariel@cthulhu.engr.sgi.com,
linux@yon.engr.sgi.com
Subject: Re: Linux: the next step
Date: Mon, 12 Aug 1996 14:49:45 -0700 [thread overview]
Message-ID: <199608122149.OAA15461@neteng.engr.sgi.com> (raw)
: > No doubt to make room for some paper on TCL scripts or something. Feh.
: > Yeah, if you can make me a copy or convince the authors to send me one I'd
: > appreciate it.
:
: Now wait a minute here. Read the paper before commenting.
: They create a "real-time" thread under Linux. That does not
: mean that it does anything, that the OS has real time support,
: etc. There was nothing particularly new about what it did.
Here's what they did: they took over control of interrupt disable/enable
and dispatch. They run Linux as a thread and allow you to have 0 or more
real time threads. If all you are doing is running Linux, it looked
to me like there was minimal impact to the performance of the system.
Real time threads run on the bare hardware, they have little
integration with the OS, other than a pipe like communications device.
The programming paradigm is you run two processes, one real time that
gathers events and stuffs them in the "pipe", and one normal that reads
events out of the pipe and does time _un_critical processing.
They can guarentee real time response of 10Khz, with less than 15 usec
variation. That was with Linux running a
tar f - /usr | (cd /newusr; tar xf -)
a web browser, X, etc, etc. Good luck doing that on IRIX up. Maybe MP.
I thought the new work was the idea of *not* buggering up your entire OS
to support real time. They give the real time guys ownership of the CPU
with minimal impact on the rest of the system. And they had to do next
to nothing to make this work, they just use Unix for everything except
the lowest level of RT work. I dunno, maybe I'm projecting some pipe
dream, but I think this is really cool work. Points for orthogonal
thinking on their part.
WARNING: multiple messages have this Message-ID (diff)
From: lm@gate1-neteng.engr.sgi.com (Larry McVoy)
To: "John E. Schimmel" <jes@machine.engr.sgi.com>
Cc: Steve Alexander <sca@refugee.engr.sgi.com>,
lm@neteng.engr.sgi.com, nigel@cthulhu.engr.sgi.com,
alambie@wellington.sgi.com, ariel@cthulhu.engr.sgi.com,
linux@yon.engr.sgi.com
Subject: Re: Linux: the next step
Date: Mon, 12 Aug 1996 14:49:45 -0700 [thread overview]
Message-ID: <199608122149.OAA15461@neteng.engr.sgi.com> (raw)
Message-ID: <19960812214945.lB4c-ORBkhOlMZtcdfWryQg2QIngDr5QQZKm1KwpGkI@z> (raw)
: > No doubt to make room for some paper on TCL scripts or something. Feh.
: > Yeah, if you can make me a copy or convince the authors to send me one I'd
: > appreciate it.
:
: Now wait a minute here. Read the paper before commenting.
: They create a "real-time" thread under Linux. That does not
: mean that it does anything, that the OS has real time support,
: etc. There was nothing particularly new about what it did.
Here's what they did: they took over control of interrupt disable/enable
and dispatch. They run Linux as a thread and allow you to have 0 or more
real time threads. If all you are doing is running Linux, it looked
to me like there was minimal impact to the performance of the system.
Real time threads run on the bare hardware, they have little
integration with the OS, other than a pipe like communications device.
The programming paradigm is you run two processes, one real time that
gathers events and stuffs them in the "pipe", and one normal that reads
events out of the pipe and does time _un_critical processing.
They can guarentee real time response of 10Khz, with less than 15 usec
variation. That was with Linux running a
tar f - /usr | (cd /newusr; tar xf -)
a web browser, X, etc, etc. Good luck doing that on IRIX up. Maybe MP.
I thought the new work was the idea of *not* buggering up your entire OS
to support real time. They give the real time guys ownership of the CPU
with minimal impact on the rest of the system. And they had to do next
to nothing to make this work, they just use Unix for everything except
the lowest level of RT work. I dunno, maybe I'm projecting some pipe
dream, but I think this is really cool work. Points for orthogonal
thinking on their part.
next reply other threads:[~1996-08-12 21:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-08-12 21:49 Larry McVoy [this message]
1996-08-12 21:49 ` Linux: the next step 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
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=199608122149.OAA15461@neteng.engr.sgi.com \
--to=lm@gate1-neteng.engr.sgi.com \
--cc=alambie@wellington.sgi.com \
--cc=ariel@cthulhu.engr.sgi.com \
--cc=jes@machine.engr.sgi.com \
--cc=linux@yon.engr.sgi.com \
--cc=lm@neteng.engr.sgi.com \
--cc=nigel@cthulhu.engr.sgi.com \
--cc=sca@refugee.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