Date: Sat, 14 Oct 1995 19:48:15 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: pete@RockyMountain.rahul.net (Pete Delaney) Cc: terry@lambert.org, jehamby@lightside.com, pete@RockyMountain.rahul.net, freebsd-hackers@FreeBSD.ORG, ports@FreeBSD.ORG, netbsd-ports@netbsd.org Subject: Re: Netscape 2.0beta1 - Port of HotJava to FreeBSD and NetBSD More Message-ID: <199510150248.TAA22335@phaeton.artisoft.com> In-Reply-To: <199510142244.AA06130@RockyMountain.rahul.net> from "Pete Delaney" at Oct 14, 95 03:44:30 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Sun's multithreading as of Solaris is a kernl/user space cooperative
> > model, with n kernel threads being mapped to m user space threads
> > (m >= n).
>
> Sure for Slowaris this approach makes sense, but Slowaris runs noticably
> lower on sun4c that SunOS does. The added flexabilty of SMP in the kernel
> forces a non-trivial performance impact on the kernel. Pyramid used macros
> that only kicked in if compiled for SMP, this avoids the problem if done
> carefully. Etherway, SMP is a lot of work.
Solaris and SVR4 use similar macros (though they are always on).
The performance pits in Solaris and SVR4 are in the VM system and in
the kernel LRU code.
The use of kernel multithreading in some of the code gives a performance
increase, even on a UP box with the SMP mutex usage instead of spin
locking in place.
SMP is not the only difference between SunOS and Solaris, and in fact,
it's one of the smallest differences with regard to performance, no
matter what your Sun hardware salesman said trying to explain why
Solaris was slower than SunOS ("but that's really OK, because...").
> Sure, but since most hackers will likely be using old Sun4c's, which cost
> from $100 to $400 for the CPU board, I doubt the performance penality for
> SMP is worth it for most FreeBSD users. Besides, waiting to get SMP
> working delays porting HotJava, I suspect that it's better to use a
> thread library like SunOS uses.
HotJava runs on SunOS? 8-).
The SMP overhead is quite negligible. And we are only talking about SMP at
all because the same sorts of kernel changes are necessary for kernel
preemption and SMP, and kernel preemption is necessary for kernel thread
to user space thread ID mapping.
> > The SunOS LWP library (a purely aioread/aiowrite/aiowait/aiocancel
> > based task switcher) is supported via the kernel calls for binaray
> > compatability reasons, but an lwp library is not provided for
> > Solaris: you are expected to use the kernel thread model.
>
> What do you mean I'm expected to use a kernel thread model? I assume
> you mean in the HotJava code. I expect it's far easier to change any
> dependancies in HotJava for Kernel bases threads than it is to
> implement SMP.
You mean kernel multithreading. SMP actually does not require kernel
multiple entrancy as long as you only implement low grain parallelism,
actually, though that's hardly a desirable stopping point.
> > SVR4.2 and above uses the same model.
>
> I read the SVR4.2 docs on SMP, and I found the Sequent SMP cod, which
> is 4.2 based, much nicer. If we are going to make NetBSD SMP, I wonder
> if it's worthwhile to ask Sequent if they would donate their Dynix OS
> SMP changes, which has been replace with a SVR4 code base, to the
> NetBSD community for integration into NetBSD.
Sequent, in fact, did not dupport kernel multithreading. So things like
inode allocation were globally non-reentrant rather than mutexing around
the freelist manipulation.
I agree that Sequent has a better memory allocator (though the SLAB
allocator in Solaris/SVR4 has advantages that needn't be lost when
supporting a Sequent style allocator).
But the entire Sequent implementation is in fact flawed, as you can
readily determine using the find command in multiple sessions and
watching processor utilization. Or ls -lR.
> In the mean time, I would think porting HotJava from a Linux port might be
> worthwhile. I heard from some of the guys at sequent that Sun got Slowaris
> faster with help from Cray. Hacking SMP in netbsd is likely a major effort.
The Linux HotJava port will use kernel multithreading. Alan Cox put
this in at the same time he put in SMP (rememebr what I said about the
problem of kernel preemption being similar to the problem of SMP caused
kernel reentrancy).
So the only thing it will buy you is a GCC build environment, not the
ability to run using a user space threading model.
> How far along is Jack Vogel on his SMP hacks?
Last time I talked to him (June), he had low grain parallelism without
kernel reentrancy. That was 4 months ago.
Kernel reeentrancy requires pushing the trap.c and interrupt code and
mutexing access on a hierarchical basis (to support easy computation
of transitive closure to prevent deadly embrace deadlocking) to all of
the various kernel components on a subsystem-by-subsystem basis. Using
a hierarchy also buys you the ability to lock the top of the hierarchy
for all unconverted subsystems, making it easier to incerementally
update the kernel instead of having to do it all at once.
I have recently made a number of changes in the system call/VFS/FS
interface to support kernel preemption/SMP, though they have not been
integrated into current (apparently because unsetting "HASBUF" in
the path component name flags field in nameifree and nfs_nameifree is
considered ugly). They also clean up some of the system call/VFS
interface kludges and the big namei/FS cn_pnbuf kludge in every
file system. NetBSD should feel free to pick these up as well.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510150248.TAA22335>