Date: Tue, 4 Jan 2000 17:03:33 -0700 From: Nate Williams <nate@mt.sri.com> To: "Richard Seaman, Jr." <dick@tar.com> Cc: Nate Williams <nate@mt.sri.com>, Amancio Hasty <hasty@rah.star-gate.com>, Bob Shaw <bob@securify.com>, emulation@FreeBSD.ORG Subject: Re: linux_base-6.1: Are Linux threads supported? Message-ID: <200001050003.RAA15774@mt.sri.com> In-Reply-To: <20000104162325.C15887@tar.com> References: <200001041947.MAA14347@mt.sri.com> <200001042127.NAA25824@rah.star-gate.com> <200001042135.OAA15019@mt.sri.com> <20000104162325.C15887@tar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. No need to be confused. :) > 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. So far so good. Again, this isn't 'native' though, as I pointed out in an earlier email. > 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. Right, this gives you the 1:1 user/kernel thread mapping. > I don't understand why I/O threads would not work well with > linuxthreads. They work fine, but tend to be too heavy when the number of active I/O threads gets large. Too many threads are spawned off, taking up too many resources and the system tends to bog down heavily. On my system, I had roughly 2000 running threads, with about 50-100 of them active at any one point. About 2/3 of them were involved in I/O of some kind, and as such would become 'kernel threads' in the kernel thread implementation. Using the green-thread implementation of the Java VM, context switches were very fast, and the use of select inside the green-thread libraries caused the application to rarely block inside the kernel. (Although, at times it did block, especially when writing to disk.) > Programs like squid work very well with linuxthreads, and AFAIK will > outperform squid compiled with FreeBSD "user" threads. "kernel > threads" should improve This is sometimes the case, but not always. In my case, the number of threads and their weight caused the program to behave very *poorly*, because it took so many more resources. The 'userland thread' implementation (using select behind the scenes) performed much better than the 'kernel thread' version. > I/O concurrency when there is I/O that blocks in the kernel. In my case, most of the time the I/O didn't block in the kernel because select was used. Keeping things 'lightweight' made it much easier to do context switching, and the number of resources used was much less. So, I state again the existing 'non-native' kernel thread implementation is not always a win. It depends on your application. > 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. They are similar to the user-land threads code that exist in FreeBSD, but are tuned specifically to the JVM. They are in fact part of the JDK implementation. However, like the existing userland threads code, they block inside of the kernel, since they have no concept of 'kernel threads'. Finally, they are not 'publically' available, so we couldn't use them even if we wanted to. The other choice in the JDK is to use 'native' kernel threads, but the existing 'kernel threads' in FreeBSD has some negative side-effects which you just spoke about. So, in summary, the Linux JDK that uses native threads is not necessarily a win because of it's use of native threads. As a matter of fact, it may be a loss, due to the architectural side-effects of the existing linux threads implementation. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001050003.RAA15774>