Date: Thu, 15 Jul 1999 18:53:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: unknown@riverstyx.net (Tani Hosokawa) Cc: davids@webmaster.com, tlambert@primenet.com, chat@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? Message-ID: <199907151853.LAA29897@usr07.primenet.com> In-Reply-To: <Pine.LNX.4.10.9907141948260.2405-100000@avarice.riverstyx.net> from "Tani Hosokawa" at Jul 14, 99 07:51:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907151853.LAA29897>