Date: Sat, 28 Apr 2001 09:38:29 +0800 From: "David Xu" <bsddiy@163.net> To: "Alfred Perlstein" <bright@wintelcom.net>, "Nate Williams" <nate@yogotech.com> Cc: "Daniel Eischen" <eischen@vigrid.com>, "Matt Dillon" <dillon@earth.backplane.com>, "Julian Elischer" <julian@elischer.org>, <Arch@FreeBSD.ORG> Subject: Re: KSE threading support (first parts) Message-ID: <002c01c0cf83$f3d594a0$cc01a8c0@xyf> References: <15081.50170.297579.938254@nomad.yogotech.com> <Pine.SUN.3.91.1010427154434.12501B-100000@pcnet1.pcnet.com> <20010427130826.G18676@fw.wintelcom.net> <15081.53821.755743.746621@nomad.yogotech.com> <20010427133433.H18676@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: Alfred Perlstein <bright@wintelcom.net> To: Nate Williams <nate@yogotech.com> Cc: Daniel Eischen <eischen@vigrid.com>; Matt Dillon <dillon@earth.backplane.com>; Julian Elischer <julian@elischer.org>; <Arch@FreeBSD.ORG> Sent: Saturday, April 28, 2001 4:34 AM Subject: Re: KSE threading support (first parts) > * Nate Williams <nate@yogotech.com> [010427 13:14] wrote: > > > > > > Well, that's complete bullshit. KSE's are extremely short-running > > > > > > affairs in kernel mode, especially when you consider the most likely > > > > > > asynchronizing case (a simple blocking situation that will most commonly > > > > > > be in a read() or write()). > > > > > > > > > > Not necessarily. My experience with developing and running applications > > > > > on Solaris says that having multiple KSE's/process is a *huge* win. > > > > > > > > You do know that the proposed implementation isn't quite like > > > > Solaris (KSEs don't get their own quantum). You better holler > > > > if you want it ;-) > > > > > > There's two things on the issue that I'd like to bring up. > > > > > > The concepts are cool, however the implementation you guys are > > > discussion really hurt my head, not in a bad way, but conceptually > > > the concepts look quite daunting. Kudos if you guys get it done > > > though! > > > > > > Being able to have threads used in a "this application wants to > > > utilize _all_ available system reasources" meaning if you have > > > more than one processor, I want to see mysql, apache, whatever > > > using it (by default!). If your model doesn't include this then > > > please don't bother continuing, the stability issues versus the > > > gain don't work for me at all. > > > > Having 'serialized' KSE's (which Matt wants) means that an application > > will be *UNABLE* to use all of the system resources, because only one > > thread in threaded application (apache, mysql, etc..) is allowed to run > > at one time, no matter how many CPU's are there. > > It doesn't seem like that's what Daniel is saying, which is that > the default will be like this, but that applications or the startup > code will have the choice. > > However that's true then we might as well scrap the project, it > just brings the complexity out of userland and into the kernel, > sure we can schedule IO better, but then we might as well cop out > and use aio and some special signal system for handling faults back > into the uts. It's just a lot simpler to go with rfork threads or > a simpler model than all this complexity just to satisfy Terry's > view of who should get what quantum. Honestly if you ask anyone > they expect to be able to cheat with threads the same way they > cheat by using multiple processes to gain additional CPU. > so you ignore NxN and MxN thread model discuss, and follow fuck Linux thread model design. maybe I can not expect such advance feature will be in Free OS. sigh, where is Jason Evans? we need your help. David Xu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002c01c0cf83$f3d594a0$cc01a8c0>