From owner-freebsd-arch Fri Apr 27 13:35:19 2001 Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 8602A37B422 for ; Fri, 27 Apr 2001 13:35:16 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f3RKYXo07478; Fri, 27 Apr 2001 13:34:33 -0700 (PDT) Date: Fri, 27 Apr 2001 13:34:33 -0700 From: Alfred Perlstein To: Nate Williams Cc: Daniel Eischen , Matt Dillon , Julian Elischer , Arch@FreeBSD.ORG Subject: Re: KSE threading support (first parts) Message-ID: <20010427133433.H18676@fw.wintelcom.net> References: <15081.50170.297579.938254@nomad.yogotech.com> <20010427130826.G18676@fw.wintelcom.net> <15081.53821.755743.746621@nomad.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15081.53821.755743.746621@nomad.yogotech.com>; from nate@yogotech.com on Fri, Apr 27, 2001 at 02:10:37PM -0600 X-all-your-base: are belong to us. Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Nate Williams [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. -- -Alfred Perlstein - [alfred@freebsd.org] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message