Date: Tue, 11 Apr 2000 10:52:55 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Terry Lambert <tlambert@primenet.com> Cc: Kirk McKusick <mckusick@flamingo.McKusick.COM>, Julian Elischer <julian@elischer.org>, Poul-Henning Kamp <phk@freebsd.org>, arch@freebsd.org Subject: Re: BUF/BIO roadmap. Message-ID: <20000411105254.F4381@fw.wintelcom.net> In-Reply-To: <200004111649.JAA17290@usr01.primenet.com>; from tlambert@primenet.com on Tue, Apr 11, 2000 at 04:49:03PM %2B0000 References: <200004110225.TAA26536@flamingo.McKusick.COM> <200004111649.JAA17290@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Terry Lambert <tlambert@primenet.com> [000411 10:18] wrote: > Kirk McKusick writes: > > > > It is my understanding that the BSD/OS MP work will soon be > > considered for incorporation into FreeBSD. Part of that > > project will include the addition of interrupt threads. > > Assuming that they go in, it will not be necessary to have > > a devd process. Beyond that, I agree with Julians comments. > > Each time interrupt threads comes up, I have to point this > out: > > Lazy Task Creation: A Technique for Increasing > the Granularity of Parallel Programs > E. Mohr, D.A. Kranz, and R.H. Halstead, Jr. > _IEEE Transactions on Parallel and Distributed Systems_ > July 1991, pages 264-280 > > It seems to me that the interrupt threads are an implementation > of this (10 year old) technology. > > > It also seems to me that kernel threads are _still_ a significantly > bad idea, since the problems faced in kernel preemption are a subset > of the problems faced in Real Time support, and that as a result, it > will be significantly harder to support Hard Real Time in the future > without significant revisions of the the OS architecture. > > I don't think the goal of code integration for the sake of code > integration is really worthwhile. I view the use of kernel thread > context switches as an alternative to addressing fine grained > parallelism through critical sectioning and object locking as a > compromise; perhaps not a good one, since this will obviously > result in register window flushing on RISC architectures, such > as SPARC. > > It seems to me that the thing to address first is that which > Dynix addressed first, and which was noted in chapter 12 0f > Uresh Vahalia's _UNIX Internal: The New Frontiers_, which is > per processor resource pools with high and low watermarking and > free resource revocation in low resource conditions. This would > significantly reduce even the need for bus and lock contention, > since contention would only occur at high or low watermark, or > as the result of a resource revocation event in an already > stressed system. I have an idea that combines both Horde and Dynix, along with improvements on the locking scheme to reduce contention. So you get the non-locking mechanisms of Dynix, but the cache saving features of horde. Btw, going to be at BAFUG? :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." 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?20000411105254.F4381>