From owner-freebsd-hackers Sat Oct 14 19:53:59 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA27403 for hackers-outgoing; Sat, 14 Oct 1995 19:53:59 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA27375 ; Sat, 14 Oct 1995 19:53:52 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA22335; Sat, 14 Oct 1995 19:48:16 -0700 From: Terry Lambert Message-Id: <199510150248.TAA22335@phaeton.artisoft.com> Subject: Re: Netscape 2.0beta1 - Port of HotJava to FreeBSD and NetBSD More To: pete@RockyMountain.rahul.net (Pete Delaney) Date: Sat, 14 Oct 1995 19:48:15 -0700 (MST) Cc: terry@lambert.org, jehamby@lightside.com, pete@RockyMountain.rahul.net, freebsd-hackers@FreeBSD.ORG, ports@FreeBSD.ORG, netbsd-ports@netbsd.org In-Reply-To: <199510142244.AA06130@RockyMountain.rahul.net> from "Pete Delaney" at Oct 14, 95 03:44:30 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5180 Sender: owner-hackers@FreeBSD.ORG Precedence: bulk > > 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.