Date: Thu, 15 Jul 1999 12:10:27 -0700 (PDT) From: Tani Hosokawa <unknown@riverstyx.net> To: Terry Lambert <tlambert@primenet.com> Cc: davids@webmaster.com, chat@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? Message-ID: <Pine.LNX.4.10.9907151200240.10288-100000@avarice.riverstyx.net> In-Reply-To: <199907151853.LAA29897@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Jul 1999, Terry Lambert 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. Thank you for spewing some geek-speak into an unrelated discussion. I welcome you to bring forth a new webserver that can duplicate everything that Apache can do with the same developer support that Apache has using a different model. Hey, maybe if can be done. Certainly, if what you say is true (I don't dispute the technical merits, since I don't know enough about them) a webserver can be built like that. However, the question that begs to be answered here is "Will you do it?" And the answer, in all likelihood, is "no". So, what we get back to is, what's one thing that's wrong with FreeBSD? Threads. Does it matter whether some other model has "the potential" to beat Apache in performance? No. People aren't going to switch to this new webserver at the drop of a hat, because Apache's a really nice, flexible webserver, that we've already torture-tested for years, and we're already familiar with it. You want to simply ignore the fact that a webserver with over 50% of the world's market share happens to require threads just because in your opinion the developers of said webserver have their heads up their ass as far as programming is concerned? That's naive. Especially when you're talking about development on what's supposedly a "server OS". The question that people are asking when they consider platforms is not "if we were going to write our own software product, what OS would we choose, if we were to adopt the most efficient paradigm?", it's "what OS will give us the best performance if we're going to use X established existing software product?" --- tani hosokawa river styx internet 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?Pine.LNX.4.10.9907151200240.10288-100000>