From owner-freebsd-smp Thu Feb 15 16:51:39 2001 Delivered-To: freebsd-smp@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id B51DA37B4EC for ; Thu, 15 Feb 2001 16:51:36 -0800 (PST) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id RAA11898; Thu, 15 Feb 2001 17:46:07 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAASEaqmx; Thu Feb 15 17:45:59 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id RAA12056; Thu, 15 Feb 2001 17:51:25 -0700 (MST) From: Terry Lambert Message-Id: <200102160051.RAA12056@usr08.primenet.com> Subject: Re: possible problem with SMP? To: nate@yogotech.com Date: Fri, 16 Feb 2001 00:51:24 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), seth@pengar.com (Seth Leigh), freebsd-smp@FreeBSD.ORG In-Reply-To: <14988.26939.53659.399934@nomad.yogotech.com> from "Nate Williams" at Feb 15, 2001 04:41:47 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > In effect, both these models are a call-conversion model, where you > > exchange a blocking call for a non-blocking call (or a block on an > > LWP, and the creation of a new LWP to continue running), plus a > > thread context switch. > > > > Neither of these models improves concurrency on a UP system. > > Sure they do. Not in all cases, but in most cases they do ipmrove > concurrency since they're allowing other threads to execute while a > non-threaded application would block on that system call. > > It does not scale as well on a UP system like SA's do, but in many case > the threading model is more effecient 'most of the time' vs. a > multi-process model. I meant in the context of allowing the code to execute concurrently; they both eliminate all the stalls you can eliminate, but the processor can't run more than one set of code at a time, if all you have is one processor. This probably wasn't clear; I've been approaching this thread from the context of threads in UP vs. SMP, since it was posted to the -smp mailing list, instead of to -arch. I've assumed that the original poster is looking at threads as a means of SMP scalability, and not from the perspective of the best way to achieve SMP scalability (i.e. it started out as a "how do I build a better hammer" discussion instead of as a "what is the right tool for this job" discussion). > > Threaded applications will block on resource unavailability; it's > > really irrelevent whether this happens in the kernel or in user > > space. > > Except the cost of 'switching context' in userland is much lower than > in the kernel. (As you said, this is the what 'Lightweight' implies > with LWP's. :) Right, exactly; and it's not just the context switch, it's the protection domain crossing, as well. On SPARC machines, this is somewhat mitigated, since even the liblwp user space threads on SunOS 4.x had a helper system call to deal with the SPARC register window problem, and that had to be called on context switches in user space, in case there was a stack frame push, but on most machines, doing as much in user space will result in significant savings. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message