From owner-freebsd-questions Mon Nov 8 11:35:32 1999 Delivered-To: freebsd-questions@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id B710A14F58 for ; Mon, 8 Nov 1999 11:35:30 -0800 (PST) (envelope-from bright@wintelcom.net) Received: from localhost (bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) with ESMTP id LAA09951; Mon, 8 Nov 1999 11:58:47 -0800 (PST) Date: Mon, 8 Nov 1999 11:58:47 -0800 (PST) From: Alfred Perlstein To: Jonathon McKitrick Cc: freebsd-questions@FreeBSD.ORG Subject: Re: threading and performance In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 8 Nov 1999, Jonathon McKitrick wrote: > On Mon, 8 Nov 1999, Alfred Perlstein wrote: > > >yes, right now only one thread of execution can be active in > >the kernel at any given time, this is going to change RSN. > > > >This really has very little to do with pthreads though. > > -jonathon > > RSN - Real Soon Now? yes. > Also, wouldn't this create bottlenecks when different processes have to > wait for a single kernel thread to finish? yup part of the problem is determining where exactly to lock, how to lock? spin? mutex? context switch? and how fine grained we want to do it. currenlt there is some locking support for long term exclusion such as in the FS code, and TCP/IP stack, the problem is that the code doesn't expect anything to be fiddling with kernel structures while it's executing, it only expects that to happen if it potentially tsleeps, or it has asserted an spl level to protect itself from device interrupts messing with variables. > I think Solaris has > multithreaded kernel support, IIRC. I just find it so interesting that > FBSD multitasks and context switches so efficiently and smoothly, and > handles such heavy loads, yet the kernel is only single threaded. I just > wondered how that was possible. The current BSD kernel locking model is quite effecient, solaris has all this fine grained locking that kills performance until you go 8-way SMP because not only are they finely grained with locking, they also support pre-emption of kernel threads. It's a nice feature but a nightmare for performance because of all the additional locking and retrys that must be done. I think the direction we will head is fine grained locking but without preemption of kernel threads, but that's still up for discussion. > It's certainly a credit to the developers > ! Frankly, if it works so well, you have to wonder if stability will be > lost finding bugs in the new version if it has multi-threaded kernel > support. He, you can't make an omlette w/o breaking some eggs, right? We don't plan on breaking anything. :) -Alfred Perlstein - [bright@rush.net|alfred@freebsd.org] Wintelcom systems administrator and programmer - http://www.wintelcom.net/ [bright@wintelcom.net] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message