Date: Tue, 11 Apr 2000 16:49:03 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mckusick@flamingo.McKusick.COM (Kirk McKusick) Cc: julian@elischer.org (Julian Elischer), phk@freebsd.org (Poul-Henning Kamp), arch@freebsd.org Subject: Re: BUF/BIO roadmap. Message-ID: <200004111649.JAA17290@usr01.primenet.com> In-Reply-To: <200004110225.TAA26536@flamingo.McKusick.COM> from "Kirk McKusick" at Apr 10, 2000 07:25:51 PM
next in thread | previous in thread | raw e-mail | index | archive | help
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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200004111649.JAA17290>