From owner-freebsd-hackers Mon Aug 12 10:40:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA01274 for hackers-outgoing; Mon, 12 Aug 1996 10:40:52 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA01262 for ; Mon, 12 Aug 1996 10:40:39 -0700 (PDT) Received: (from narvi@localhost) by haldjas.folklore.ee (8.6.12/8.6.12) id UAA11087; Mon, 12 Aug 1996 20:48:28 +0300 Date: Mon, 12 Aug 1996 20:48:27 +0300 (EET DST) From: Narvi To: Terry Lambert cc: Igor Khasilev , freebsd-hackers@FreeBSD.ORG Subject: Re: FreeBSD vs. NT Stability In-Reply-To: <199608121654.JAA25508@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 12 Aug 1996, Terry Lambert wrote: > Obviously, the ideal mechanism is combined kernel and user threads, > with cooperative scheduling of kernel process quantums in user space > against the thread contexts that are blocked awaiting quantum. This > will result in the best overall utilization with the fewest true > context switches. > And is FreeBSD going to get this? It would be cool... Multi-threaded servers for different things (http, etc) are becoming to emerge more. > > The primary benefit of kernel threads is SMP scalability of parallelizable > algorithms. The secondary benefit of kernel threads is in terms of > quantum allocability as a gross measure of how zealously you want to > let your threads compete with other processes which are also competing > for quantum. > > > There are a number of usenet discussions on threading between myself > and engineers at Sun and elsewhere; you can look them up on Dejanews. > > > Since kernel threading is heavily related to SMP scalability of > processes, the SMP group of FreeBSD has dealt some with the issue. > One very good engineer has implemented kernel threading on FreeBSD, > and the code has been submitted; from what I understand, the code > will be integrated into the final SMP release, with only minor > changes. > Are there any plans for integration with the user level pthreads implemetation? Sander > > The resoloution of the kernel threading quantum and context switch > problems (current problems for both SVR4 and Solaris threading, which > are derived from the same Sun code base) will have to wait for better > async->sync call conversion. In all likelihood, this will be implemented > by adding a system call for a more generic "aiowait/aiocancel" that > is not so I/O bound, and an alternate system call vector to allow all > potentially blocking system calls to be converted to queued calls > plus a user space context switch. In this way, the kernel threading > problem of blocking thread execution and throwing away perfectly good > quantum on process context switches, can be eliminated. > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. >