From owner-freebsd-chat Thu Jul 15 11:55:11 1999 Delivered-To: freebsd-chat@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id A349F14E21 for ; Thu, 15 Jul 1999 11:55:08 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA10908; Thu, 15 Jul 1999 11:53:59 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd010858; Thu Jul 15 11:53:50 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA29897; Thu, 15 Jul 1999 11:53:48 -0700 (MST) From: Terry Lambert Message-Id: <199907151853.LAA29897@usr07.primenet.com> Subject: Re: Known MMAP() race conditions ... ? To: unknown@riverstyx.net (Tani Hosokawa) Date: Thu, 15 Jul 1999 18:53:47 +0000 (GMT) Cc: davids@webmaster.com, tlambert@primenet.com, chat@FreeBSD.ORG In-Reply-To: from "Tani Hosokawa" at Jul 14, 99 07:51:46 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org tani hosokawa wrote: > > The current model is a hybrid thread/process model, with a number of > processes each with a large number of threads in each, each thread > processing one request. From what I've seen, 64 threads/process is about > right. So, in one Apache daemon, you can expect to see >1000 threads, > running inside 10-20 processes. Does that count as a large number? The question that begs to be answered here is "On what platform?". If the answer is Solaris, then it's running a hybridized kernel/user space cooperative scheduler. The difference between this and an async call gate based call conversion scheduler is the need to signal for lazy kernel thread creation as a result of N outstanding blocking calls for N+1 currently existing threads (+1 is the scheduler/new thread creator). Such a scheduler is (potentially) much less efficient than one that doesn't require for protection domain crossings for the lazy binding, and fully utilizes its quantum, instead of spending it doing unnecessary kernel scheduler work and kernel thread thrashing in the case of an M:N . user space thread vs. kernel thread backing model (M > N), but it's *vastly* better than what Linux or FreeBSD have today (at least in terms of SMP scalability for the FreeBSD user space threads implementation). For non-SMP systems (the benchmarks in question used 4 processor Xeon boxes, so this is rather non-applicable to benching IIS on NT against Apache on FreeBSD), the FreeBSD user space call conversion scheduler has the potential to beat the hybridized model by a significant margin, assuming the register window and signal crap is de-POSIX'ed. 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-chat" in the body of the message