From: W B Hacker <wbh@conducive.org>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] slow performance
Date: Sun, 1 Apr 2007 03:27:11 +0800 [thread overview]
Message-ID: <460EB60F.5070409@conducive.org> (raw)
In-Reply-To: <5d375e920703311012l41d6647fndbcea417c3d52a7b@mail.gmail.com>
Uriel wrote:
>> But a guess: ISTR seeing that the Plan9 kernel 'lacked a scheduler'.
>> That can be inconsequential for some situations, very important for
>> others.
>
> Could you please explain this? I'm still baffled as to what you mean.
No need. As said - stale info. You've just clarified it, thanks!
But .. there IS a plethora of stale info and - perhaps worse - broken links -
all over what Google finds as the Plan9 'universe'.
Sometimes hard to ascertain the date of the pages, as well.
>
> As far as my limited knowledge goes, Plan 9 has had an SMP aware
> scheduler since ancient times[1](I think before 1st Ed), and in more
> recent times a real time scheduler[2] has been added.
>
ACK. I've saved a couple of .pdf presentations discussion how it *could be*, but
not clear to me that it *had been*.
> So I'm puzzled as to how Plan 9 could 'lack a scheduler'.
So am I. Though my present interest is not so much lack of a scheduler, as
curiousity as to how it prioritizes, (e.g. equivalents to 'nice', runlevels, et al).
>
> I also would recommend at least taking a look at the performance
> section of http://plan9.bell-labs.com/sys/doc/9.html
>
> uriel
>
> [1] http://plan9.bell-labs.com/sys/doc/sleep.html
> [2] http://purl.org/utwente/fid/1149
All great stuff - and outlining what the benefits of Plan9 were/are/should be.
But dated. Been a while since a 100 MHz Irix was top dog, if ever was.
How much, if any, of what Plan9 is/was has been overtaken by events? And for
better? Or for worse?
For example - Alef's parallizing features are noted, extolled, and:
"Although it is possible to write parallel programs in C, Alef is the parallel
language of choice."
Which raises the question (in my own mind at least) as to how much and how well
this has been preserved and extended in 'C' with Alef having left the building
with Elvis.
And what penalty comes with the benefit of communication by text stream vs
binary? And via a fs call (whether in cache/RAM or not), vs
closer-to-the-CPU-core. Registers, even.
'Universality and 'portability' are perhaps not such a big deal when very few
processor families are supported.
Granted - Plan9 does not, in most instances, attempt to do things in the same
way - or even do them *at all* - that a 'big iron' OS, a *BSD or Linux might do,
so head-to-head comparisons would certainly not be as easy as point and click
(or ..mouse chord...).
And I *have* seen some impressive figures mentioned for time to boot a large
grid from a cold start vs other OS'en.
But where can I/we find 'evidence' - current evidence - that all this is more
than a theoretical exercise?
A place where Plan9 holds the high ground in real-world use, so to speak.
Thanks for the patience...
Bill
next prev parent reply other threads:[~2007-03-31 19:27 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-31 16:41 pedro henrique antunes de oliveira
2007-03-31 16:48 ` Lorenzo Fernando Bivens de la Fuente
2007-03-31 16:48 ` Charles Forsyth
2007-03-31 16:57 ` pedro henrique antunes de oliveira
2007-03-31 16:55 ` W B Hacker
2007-03-31 17:12 ` Uriel
2007-03-31 19:27 ` W B Hacker [this message]
2007-03-31 23:20 ` erik quanstrom
2007-03-31 23:35 ` pedro henrique antunes de oliveira
2007-04-01 1:40 ` erik quanstrom
2007-03-31 17:15 ` Charles Forsyth
2007-03-31 18:50 ` Armando Camarero
2007-03-31 21:05 ` C H Forsyth
2007-03-31 23:25 ` pedro henrique antunes de oliveira
2007-04-01 1:32 ` erik quanstrom
2007-04-01 9:22 ` Charles Forsyth
2007-04-01 9:52 ` pedro henrique antunes de oliveira
2007-04-01 9:56 ` pedro henrique antunes de oliveira
2007-04-01 18:24 ` ron minnich
2007-04-01 19:11 ` pedro henrique antunes de oliveira
2007-04-01 19:26 ` geoff
2007-04-01 19:57 ` pedro henrique antunes de oliveira
2007-04-01 20:07 ` Charles Forsyth
2007-04-01 20:11 ` pedro henrique antunes de oliveira
2007-04-01 20:26 ` Charles Forsyth
2007-04-01 21:13 ` ISHWAR RATTAN
2007-04-02 1:52 ` pedro henrique antunes de oliveira
2007-04-01 12:08 erik quanstrom
2007-04-01 12:35 ` pedro henrique antunes de oliveira
2007-04-01 14:39 ` Uriel
2007-04-01 15:11 ` C H Forsyth
2007-04-01 17:35 ` pedro henrique antunes de oliveira
2007-04-01 18:05 ` erik quanstrom
2007-04-02 9:14 phao
2007-04-02 9:31 ` Anselm R. Garbe
2007-04-02 9:38 ` Charles Forsyth
2007-04-02 9:42 ` C H Forsyth
2007-04-02 9:45 ` Anselm R. Garbe
2007-04-02 12:49 ` pedro henrique antunes de oliveira
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=460EB60F.5070409@conducive.org \
--to=wbh@conducive.org \
--cc=9fans@cse.psu.edu \
/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;
as well as URLs for NNTP newsgroup(s).