Date: Fri, 16 Feb 2001 00:51:24 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@yogotech.com Cc: tlambert@primenet.com (Terry Lambert), seth@pengar.com (Seth Leigh), freebsd-smp@FreeBSD.ORG Subject: Re: possible problem with SMP? Message-ID: <200102160051.RAA12056@usr08.primenet.com> In-Reply-To: <14988.26939.53659.399934@nomad.yogotech.com> from "Nate Williams" at Feb 15, 2001 04:41:47 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102160051.RAA12056>