Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!newsfeed.internetmci.com!xmission!news.cc.utah.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@lambert.org>
Newsgroups: comp.unix.bsd.netbsd.misc,comp.unix.bsd.bsdi.misc,comp.unix.solaris,comp.unix.aix
Subject: Re: ISP hardware/software choices (performance comparison)
Date: 15 Jan 1996 20:15:10 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 197
Distribution: inet
Message-ID: <4decke$6nh@park.uvsc.edu>
References: <4cmopu$d35@vixen.cso.uiuc.edu> <4cu7t0$mg5@engnews2.Eng.Sun.COM> <4cv8j1$59k@park.uvsc.edu> <4d37d4$j0l@gremlin.backfire.mn.org> <DL29Az.Ax2@ftel.co.uk> <bryDL3r9p.2oq@netcom.com> <4da5nl$8l5@news.voicenet.com> <bryDL5wtq.4Fo@netcom.com> <4dc00a$j2f@park.uvsc.edu> <bryDL7E84.LG3@netcom.com>
NNTP-Posting-Host: hecate.artisoft.com
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.netbsd.misc:1839 comp.unix.bsd.bsdi.misc:1971 comp.unix.solaris:56608 comp.unix.aix:68179
bry@netcom.com (Bryan Althaus) wrote:
] True. What I really was trying to say is that SunOS 4.1.x had
] pthreads slapped into it where as Solaris (among other OS's)
] was designed from the start to support threads with support
] throughout the kernel.
Standard pthreads (per Chris Provenzo's work and the CompuServe
code for 386BSD) is a different animal than LWP.
If you really meant pthreads and not LWP, then yes, it was a
slap-in, mainly because it wasn't part of the OS at all.
If you meant LWP, I think you are mistaken (though the University
of Washington papers are the source of LWP, not Sun).
] Also designed in from the being with Solaris was support for
] SMP.
SMP support is relative. For low grain support, a small scheduler
hack and startup code are all that's needed -- that an a kernel
entrancy mutex.
For fine grain parallelism (where several processors are in the
kernel at the same time), you need to be able to support kernel
reentrancy. And yes, I realize that this is exactly analogous
to the problem of kernel preemption, and it's a small step from
there to kernel multithreading.
] I always here people say "Other than SMP .." as if it's trivial
] to have an OS support SMP. If it was so easy Linux and *BSD
] would have it.
Linux has it. FreeBSD has had it since 28 Oct 1994. I have it
on an ASUS dual P90 box not three feet away from me.
Do you mean that it would be integrated into the source tree
instead of available as patches? That's a different problem.
I have a lot of FS work that you could make the same claims
about. Including kernel patches for the first non-commercial
NFS locking implementation. This is the problem with a public
rather than a commercial project: people work with you (or don't)
because the want to (or don't), not because they are paid to do
so.
] Once you have SMP, all sorts of race conditions come into play
] and since your a kernel hacker (I'm not) you know this.
Yeah. It's relatively trivial to use a variable granularity
locking mechanism to "push down" the threading issues so that
they can be dealt with on a per subsystem basis. The first
step is pushing down the interrupt and trap code from a single
reeentrancy lock, and then going from there.
Yes, it's a problem. Problems can be solved.
If you want to argue quality of implementation, I'll take the
VFS vncalls layer implementation in Unisys's MP kernel over the
per FS crap in the Solaris kernel any day for allowing third
parties to actually write file system components.
] Add support for kernel threads as does Solaris and I'm
] surprised you don't have more respect for the job Sun has
] done with Solaris.
This is trivial once you have kernel preemption; you just
need to make a choice of which kernel thread read to run is
allowed to run -- basically, you add preemption points.
If you have ever done a streams implementation, choice of
preemption points (generally derived from profiling information
unavailable on a system without a high granularity clock or
special hardware, like an ICE) is rather trivial.
] Oh, add support for soft real-time classes in if the task is
] too easy.
I admit this is harder. On the other hand, the soft real-time
support in Solaris is event rather than deadline based. I would
be much more impressed with a deadlining mechanism.
To support RT requires only the ability to kernel preempt, and
either internal preemption points or a good timer mechanism
(that SVR4 doesn't have, BTW) for reschedulable one-shots. Then
you just need multiple run queues giving priority to the "RT"
queue. You handle priority inversion the simplest way possible:
extend the resource blocking mechanism and implement basic
priority lending. Voila.
] Do you really think had Sun taken SunOS 4.1.x and band-aided
] SMP & kernel threads into the OS that the OS would be better
] than what they currently have with Solaris 2.5?
No. But you are presupposing a "band-aid" approach to the task,
so my answer can only *be* "no". Sequent didn't seem to have a
problem with BSD, though they switched over to SVR4 (and lost FS
multithreading at the same time) for the same government contract
reasons predating the fall of the defense industry.
I think if they did a reasoned implementation, your question
would have a "yes" answer.
] I've heard/read that SunOS 4.1.x was starting to bust at the
] seems and was in need of a rewrite.
Maybe, maybe not. SVR4's in the same boat, but no one is
rewriting it, so it really soen't make sense to replace 4.x
technology with 5.x if that's your main argument for doing so.
] Haven't you ever worked on application code that was written
] 10 years ago, by numerous people, most who are no longer around,
] that was designed to do a certain task but over the years has
] been added to until your at the point that a complete rewrite
] is needed. A well, thought out from the beginning, this is
] what the application now needs to do rewrite?
Yeah. I worked on kernel code in SVR4 SMP at Novell USG. I'd
say that describes the SVR4 SMP code pretty well.
] I just see Sun as coming to that conclusion when they came
] out with Solaris.
Buying technology from a third party doesn't make it new.
And much of the SVR4 technology came out of Sun/BSD anyway,
not the other way around.
] The idea that Solaris was just a marketing attempt just
] doesn't hold water. SunOS already had alot of SYSV in it
] for the Wall St/Fortune 500 types.
Wrong. SVID compliance was a prerequisite for bids on govenment
contracts. DEC protested on the basis of VMS, but they lost.
The origin of the SVR3 changeover at SCO was the SCO Federal
Systems Group for the Desktop III and AFCAC-451 RFP's basic
requirements documents.
I have to assume that you weren't around in the industry in
1989 and 1990?
I happen to know about the Desktop III and AFCAC 451 requirements
because at the time I worked for a company that was one of the
few who received "sole-source justification"... we were on the
bids of every major player on those contracts.
[ ... Solaris ... ]
] : It is *not* "state of the art"; even if you limit yourself to
] : discussing only commercially sold UNIX platforms, there's AIX,
] : which has a lot of features that Solaris doesn't (and is a good
] : example of "design up front").
]
] Which version of AIX? Is AIX better than SunOS 4.1.x? FreeBSD?
] Just trying to get a handle since I know your a bright person but
] your bias for OS's is quite strong. SunOS & FreeBSD are you fav's
] and I know you were high on UnixWare for awhile, so just *exactly*
] what can Sun do to make Solaris better? Seriously. And name the
] features AIX has ( I've heard AIX is nice ) that Solaris lacks
] *maybe* they'll get in there.
AIX features that are more modern than equivalents in Solaris:
1) Dynamically sized kernel structures. Solaris has made
some headway in this direction, but AIX beats *everyone*
else cold.
2) Motif environment shipped with system by default.
3) Clone devices for PTY's, not limited by range.
4) Full utilization of a device file system paradigm.
5) Sample FS source code available in supplementary
documentation.
6) Sample device driver source code available in suplementary
documentation.
7) Well documented kernel interface for kernel subsystems,
including kernel level file I/O (no locking facilities,
but that's easy to hack given the header file structures
and knowledge of the gnode interface).
8) Thread stacks are not required to be preallocated at some
limited size; they will be grown as needed, just like
regular process stacks (UnixWare has support for this
as well, but does not make use of the VM facility).
9) Unified system management interface, including API's
for SNMP (IBM's code accompanied the SNMP II RFC).
10) A kernel that is *never* recompiled by the customer.
A lot of people don't like AIX -- for amny, it's "too alien".
But a good idea is a good idea, no matter where it comes from.
Regards,
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.