From owner-freebsd-arch Tue Apr 11 10: 9:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id D64CF37BC2C for ; Tue, 11 Apr 2000 10:09:33 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id TAA16209 for ; Tue, 11 Apr 2000 19:09:33 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA08308 for freebsd-arch@freebsd.org; Tue, 11 Apr 2000 19:09:28 +0200 (CEST) Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 0A28E37BAE8; Tue, 11 Apr 2000 10:07:36 -0700 (PDT) (envelope-from julian@elischer.org) Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id BAA12536; Wed, 12 Apr 2000 01:07:33 +0800 Received: from jules.elischer.org (reggae-11-63.nv.iinet.net.au [203.59.69.63]) by muzak.iinet.net.au (8.8.5/8.8.5) with SMTP id BAA29285; Wed, 12 Apr 2000 01:07:30 +0800 Message-ID: <38F35AC2.237C228A@elischer.org> Date: Tue, 11 Apr 2000 10:02:58 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Terry Lambert Cc: Kirk McKusick , Poul-Henning Kamp , arch@freebsd.org Subject: Re: BUF/BIO roadmap. References: <200004111649.JAA17290@usr01.primenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert 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. As I have mentionned to you before. Just because something is a 10 year old idea does not make it bad. I think that making everything a thread with a blockable context, whether initiate from above or below, makes a lot of sense and significantly reduces the complexity of the fine-grained-SMP work that needs to be done. I also would like to point out that handling interupts is a significant part of hard-realtime, and that if the lowest level of the interrupt code is kept 'under control' then solutions imposed at this level in the non threaded case are also applicable in the threaded case. The lowest level is basically the same until the control is 'morphed' into a thread. > > 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 believe this to not be the case in reality. Once control has been handed to an interrupt thread, that thread can be suspended in favour of the realtime process. This is not an option with the current system and actually gives a lot of possible options not presently available in handling RT operations. > > 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. The use of "lazy kernel threads" does not significantly alter the usage of registers from the current usage. > > 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. There has been no argument that this is probably a good idea in the long run. The use of lazy kernel threads for interrupt handling in no way interferes with this as the two features are orthogonal. This is only my opinion and not absolute truth. however it would be good to get people to discuss this topic a bit morenspecifically those from BSDI who have experience with the actual implementation. -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message