Date: Wed, 14 Feb 2001 22:34:57 -0500 From: Seth Leigh <seth@pengar.com> To: freebsd-smp@FreeBSD.org Subject: Re: possible problem with SMP? Message-ID: <5.0.2.1.0.20010214222040.00aac5c0@hobbiton.shire.net> In-Reply-To: <20010214191110.D78224@mollari.cthul.hu> References: <Pine.GSO.3.96.1010214142231.6504A-100000@p1> <Pine.GSO.3.96.1010214142231.6504A-100000@p1>
next in thread | previous in thread | raw e-mail | index | archive | help
Actually, The Many to Many threading model has been talked up a lot in the past as being better than the One to One model, and I know that I used to believe the talk. I am not so sure anymore. Check out in Solaris 8 the alternate threads library. Do a man on threads and it talks about it. It's in /usr/lib/lwp/libthread.so rather than the standard threads library /usr/lib/libthread.so. The alternate libthread is a One to One model, where all threads are bound automatically, and it isn't possible to create unbound threads, or pure user-level threads. Although it has been said in the past that user-level threads have advantages in terms of scheduling not requiring context switches and all, but there are advantages to making threads bound as well. Consider what many multi-threaded applications do with threads. Many threaded apps have threads which make blocking system calls. On Solaris, when a user-level thread blocks on the lwp it is running on, the kernel has to tell the threads library to create another lwp so that the remaining runnable user-level threads don't get starved for CPU time. Since many threaded apps use threads which all can block, the threads end up causing lwps to be created anyhow. Then, when the thread blocks itself in the threads library (eg: blocks on a mutex, or waits on a condition variable), the lwp is parked for 5 minutes, after which it is released. Well, the a few minutes later the thread is rescheduled onto an lwp and then blocks in the kernel, and we are back to square one. This can lead to lwp churning, whereas if you had just made the threads bound it wouldn't have been an issue. Additionally, a threads library that is strictly One to One is much simpler, and therefore can be more thoroughly debugged and perhaps more efficient. I hear that Sun is considering carefully the future of the threads library, doing very thorough testing on a variety of real-world multi-threaded applications, and that a switch from the current Many to Many model to a more simple One to One model is *not* out of the question. Indeed, they are supposed to be considering it seriously. To be honest, if FreeBSD can just get a threads library that uses a One to One ratio of threads to lwps (I am quite ignorant as to whether FreeBSD has the equivelant of the LWP structure, so just substitute process or whatever if I am off) I would be quite happy, and I am sure that performance would be just fine. Besides, Solaris 8 on modern UltraSparc machines runs in 64-bit mode by default. A large 64-bit Solaris 8 machine with enough RAM can support up to something like 81,000 lwps. I hardly think that "using too many kernel resources" is going to be an issue for such a system with a One to One threads model. Indeed, with a 1 MB default thread stack size, the application is more likely to be limited in how many threads it can create just do to limited physical RAM than it is to be limited by how many lwps the kernel can support (well, I must keep in mind that Solaris won't actually map any physical RAM to any given page in that 1 MB thread stack until and unless an access is made into an address in that page, but still, 81,000 threads would be an awful lot...). I would be very much interested to see just how FreeBSD intends to Do Threading Right. Seth At 07:11 PM 2/14/2001 -0800, you wrote: >On Wed, Feb 14, 2001 at 02:31:30PM -0500, Russell Francis wrote: > > > 50%. I have a threaded application that also runs but no faster that on a > > UP kernel. I am just wondering what is going on here any tips on how to > > find out would be appreciated thanks. > >This is actually a FAQ. FreeBSD's userland threads library runs within >a single process, so it's not scheduled over multiple CPUs. This is >very efficient for UP systems, but not optimal for SMP machines. > >The LinuxThreads port is an example of rfork()-bases threads (it's a >native port of the Linux code) which may be more efficient on SMP for >your application. LinuxThreads is also far from optimal - a project is >underway to Do Kernel-Supported Threading Right (see the list archives >or www.freebsd.org/~jasone/kse) but won't be ready before 6.0-RELEASE, >probably. > >Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.0.2.1.0.20010214222040.00aac5c0>