From owner-freebsd-emulation Tue Jan 4 14:23:48 2000 Delivered-To: freebsd-emulation@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 8DC8A14DD4 for ; Tue, 4 Jan 2000 14:23:42 -0800 (PST) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id QAA29153; Tue, 4 Jan 2000 16:23:25 -0600 (CST) (envelope-from dick) Date: Tue, 4 Jan 2000 16:23:25 -0600 From: "Richard Seaman, Jr." To: Nate Williams Cc: Amancio Hasty , Bob Shaw , emulation@FreeBSD.ORG Subject: Re: linux_base-6.1: Are Linux threads supported? Message-ID: <20000104162325.C15887@tar.com> References: <200001041947.MAA14347@mt.sri.com> <200001042127.NAA25824@rah.star-gate.com> <200001042135.OAA15019@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001042135.OAA15019@mt.sri.com>; from nate@mt.sri.com on Tue, Jan 04, 2000 at 02:35:50PM -0700 Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 04, 2000 at 02:35:50PM -0700, Nate Williams wrote: > > > > I'd like to install Blackdown JDK 1.2.2 RC3 on FreeBSD 3.4 > > > > with linux_base-6.1. I know there are some Blackdown problems with > > > > native threads, but I have not been able to determine whether there > > > > are any FreeBSD-specific problems that will remain once Blackdown > > > > gets their release fixed. Will native threads at the JDK level map to > > > > native threads at the FreeBSD 3.4 level? (If so, is there any idea how > > > > performance will compare to native Linux?) > > > > > > FreeBSD has no native 'kernel threads', so it won't help out. However, > > > the Linux JIT is a *big* improvement. > > > > I could have sworn to have used linux kernel threads in FreeBSD 8) > > Linux kernel threads are not native kernel threads. They are not part > of the standard distribution, they have an incompatible license, and do > not scale very well on most Java applications. However, for *certain* > applications they do work, but these are limited to mostly CPU-bound > applications that do light I/O. Applications that have lots of I/O > threads will not work well with the Linux-threads stuff. (While > applications run with the green-threads version tends to work *very* > well, almost as well as C code.) I'm confused by all this. For more than a year the FreeBSD linuxulator has had a functioning "clone()" syscall. AFAIK it works fine with the libpthread that ships with recent versions of linux, as long as its used with a compatible version of linux glibc. If you want SMP threads in the linuxulator, you need to be running FreeBSD-current. If you're UP, then AFAIK any version of 3.X since about last April or May is ok. I don't understand why I/O threads would not work well with linuxthreads. Programs like squid work very well with linuxthreads, and AFAIK will outperform squid compiled with FreeBSD "user" threads. "kernel threads" should improve I/O concurrency when there is I/O that blocks in the kernel. Each linuxthreads context switch involves a syscall. If you have a threads implemenation that can do some context switches without making a syscall (should be very doable, but FreeBSD user threads isn't there at this point), then those context switches should be *much* faster than linuxthreads, because a syscall is so expensive. I have to assume that the "green-threads" you are referring to are different than FreeBSD user threads. If they're that much faster that linuxthreads (which are very competitive with FreeBSD user threads at the moment), and if they can handle "concurrent I/O" like kernel threads, then I would assume that Jason Evans and the threads discussion that has been going on in the -arch mailing list ought to look very closely at this implementation. It sure sounds much better than anything FreeBSD has now. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message