Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!yeshua.marcam.com!charnel.ecst.csuchico.edu!xmission!u.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (Terry Lambert)
Newsgroups: comp.os.386bsd.misc
Subject: Re: dual procesor motherboards the way forward?
Date: 3 Oct 1994 22:46:15 GMT
Organization: Weber State University, Ogden, UT
Lines: 91
Message-ID: <36q1jn$4f7@u.cc.utah.edu>
References: <Cww6x9.1A0@gnome.co.uk> <36hous$fdv@exile.oec.com> <jmonroyCx10rt.4FF@netcom.com>
NNTP-Posting-Host: cs.weber.edu
In article <jmonroyCx10rt.4FF@netcom.com> jmonroy@netcom.com (Jesus Monroy Jr) writes:
[ ... discussion of MACH 3.0 for SMP ... ]
] I disagree with both your premises.
] I beleive, first, that the Mach kernel "model" is
] inefficent and is not a good choice for SMP.
I'd agree with this statement, but it's misleading in the extreme. The main
problem with the MACH model is in multiply crossing protection domains to
implement kernel sevices, and it is getting to the point where this is no
longer necessary (using page anonymity protection schemes in a 64 bit
address space).
Chorus in particular is a microkernel that has eliminated much of the
domain crossing, although instead of anonymity, they use direct function
binding and "trusted" server -- in other words, they push the severs from
"user sspace" into "kernel space".
Any college or university interested in Chorus should be aware that it is
only $1000 for a source license. Contact them for more information (the
contact point is posted in the comp.os.chorus FAQ).
] Bill Jolitz agrees to an extent with me.
I would hope that he didn't agree with you 100% on that particular issue!
] He has thrown out the Mach memory manager from
] 386bsd; claiming - it was getting in the way.
Well, yes and no -- memory overcommit and using files as swap store
*does* get in the way of scheduling a process to run without giving it a
"preferred" CPU (potentially a good idea, in a lot of ways, although you
would want to be able to dynamically reassign it on a full swap out or in
the process of load balancing). On the other hand, I don't think these
are attributes of the memory management more than they are particular
implementation choices. SVR4 SMP (UnixWare 2.0) does quite well with a
"MACH style" VM system. It has other issues relating to per process
working sets not being enforced and a linker that mmap's all the .o files
and tickles this problem.
] I state that the thread management and thread scheme
] are definitely in the way.
Not true. I personally detest the idea of kernel and user threads in
Solaris and SVR4 ("Beyond Multiprocessing: Multithreading the SunOS Kernel",
Summer 92 Usenix /ftp.sage.usenix.org/ and "Solaris SunOS 5.0: SunOS 5.0
Multithread Architecture", Sun white paper /ftp.sun.com/). In particular,
there is an implied requirement to implement SVR4 style scheduling classes
for an n:m mapping of user space to kernel threads, since the multithreaded
process is inferior to multiple processes in its ability to compete for
process quantum otherwise. In addition, the implementation is such that
the number of kernel threads (m) for user space threads (n) must be set
so that n == m. Failure to do this means compute starvation for n - m
threads for n > m, since each blocking operation in the kernel requires
its own thread. MACH's kernel threading is definitely the right direction,
and follows on the 'logical next step' after the LWP model, where a sync
operation is traded for an async operation plus a context switch ("Register
Windows and User-Space Threads on the SPARC", David Keppel University of
Washing CS department /wuarchive.wustl.edu/).
] So without getting into theoritical (sp?) discussions.
] I'd say wait for 386bsd Release 1.0.
This is a bit glib; why avoid the theoretical discussions? Since 386BSD 1.0
is currently theoretical, this will only serve to convince others (perhaps
unfairly) that you simply don't know what you are talking about.
] Reason: Bill has had a Compac MP machine in-house
] and has found many inconsistences in MACH design
] or traditional thing.
Well, the cache coherency model on the Proliant systems leaves something
to be desired, like "a cache coherency model". You can't fault Compaq on
this, as least not too much, since the same thing is true of the MiPS R4xxx
processers using the supplied MiPS SMP bus arbitration chips: they do
cache invalidation instead of cache writeback. I know of at least one
ASIC design that was in progress that did the right thing: cache update,
and arbitrated in a single clock, but the design is limited to 4 processers
and sadly has yet to see silicon.
I'd be much more interested in a design that allowed for the Intel model
of SMP (see ftp.intel.com), or even better, MPPC (PReP compliant) SMP
hardware. Both of these will be widely applicable to a large number of
hardware platforms in a very few years.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.