Date: Wed, 14 Feb 2001 22:37:11 -0700 (MST) From: Nate Williams <nate@yogotech.com> To: Seth Leigh <seth@pengar.com> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: possible problem with SMP? Message-ID: <14987.27399.662691.291906@nomad.yogotech.com> In-Reply-To: <5.0.2.1.0.20010214234050.026959f8@hobbiton.shire.net> References: <5.0.2.1.0.20010214222040.00aac5c0@hobbiton.shire.net> <Pine.GSO.3.96.1010214142231.6504A-100000@p1> <20010214191110.D78224@mollari.cthul.hu> <5.0.2.1.0.20010214234050.026959f8@hobbiton.shire.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> I don't see the logic in the argument "letting the kernel scheduler handle > the scheduling of all the threads (via lwps) is bad, because it overloads > the kernel scheduler, so we are going to do all of this thread scheduling > using a user-level thread scheduler". That's not the only thing. IMO, the single-biggest gain from a many-many mapping is that 'userland threads' are much lighter weight than any kernel thread doing context switching. The kernel has alot more context it must keep track of, and the fact of the matter is that in many cases, there is no need for multiple 'kernel' threads of execution. For a good example of this, I'll use Solaris itself. JDK1.1.8 using Green Threads and the stock JIT can often *blow the doors off* the same setup using kernel threads in many applications. From talks given at JavaOne, this is primarily because of the 'context switching' overhead of using kernel threads. (Sun's JDK uses a one-one mapping, because Java has no way of intelligently determining which threads should stay in the userland, vs. which need to own a 'kernel' context.) However, it turns out that it's *really easy* to blow yourself up and cause massive slowdowns if your Java application calls certain kind of I/O processes (in particular, read directly from stdin, or writing to files). Because there is no way to determine if a thread is going to do this kind of thing a-priori, Sun changed their default threading model in subsuquent versions of the JDK to use kernel threads. In most cases, the people won't see a measurable difference, but in certain cases they no longer see big 'pauses' due to syscalls that previously blocked all running threads. However, if performance is a goal, a properly written Java application can run faster using the 'many-one' model, where 'many threads' are mapped to a single kernel thread. Unfortunately, because Java doesn't support the 'many-many' model, you can't really choose the appropriate context for your thread to run in, and make Java run even better on your hardware. Kernel context switches are simply expensive, and even if they aren't as expensive, simply moving back-forth into the kernel is expensive because of the safety precautions that must be taken if you want the system to be robust. Nate 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?14987.27399.662691.291906>