From owner-freebsd-smp Wed Feb 14 21:37:17 2001 Delivered-To: freebsd-smp@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id D110F37B4EC for ; Wed, 14 Feb 2001 21:37:14 -0800 (PST) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA12300; Wed, 14 Feb 2001 22:37:13 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id WAA04286; Wed, 14 Feb 2001 22:37:12 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14987.27399.662691.291906@nomad.yogotech.com> Date: Wed, 14 Feb 2001 22:37:11 -0700 (MST) To: Seth Leigh Cc: freebsd-smp@FreeBSD.ORG Subject: Re: possible problem with SMP? In-Reply-To: <5.0.2.1.0.20010214234050.026959f8@hobbiton.shire.net> References: <5.0.2.1.0.20010214222040.00aac5c0@hobbiton.shire.net> <20010214191110.D78224@mollari.cthul.hu> <5.0.2.1.0.20010214234050.026959f8@hobbiton.shire.net> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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