From owner-freebsd-arch Sat Apr 15 8:12:57 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 B23F637B5B2 for ; Sat, 15 Apr 2000 08:12:55 -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 RAA20934 for ; Sat, 15 Apr 2000 17:12:53 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id RAA12372 for freebsd-arch@freebsd.org; Sat, 15 Apr 2000 17:12:53 +0200 (CEST) Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 7B87737B660; Sat, 15 Apr 2000 08:11:26 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id JAA14076; Sat, 15 Apr 2000 09:11:01 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <38F886CA.A1E99CDE@softweyr.com> Date: Sat, 15 Apr 2000 09:12:10 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Terry Lambert , Kirk McKusick , Poul-Henning Kamp , arch@freebsd.org Subject: Re: BUF/BIO roadmap. References: <200004111649.JAA17290@usr01.primenet.com> <38F35AC2.237C228A@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > Terry Lambert wrote: > > > > 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. Note that most RTOS implementations take this approach as well. In VxWorks, many interrupt handlers simply "give" a semaphore, allowing the associated driver task to drain the hardware at the programmer- determined correct priority. This also avoids interrupt livelock on saturated systems. > 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. In a pervasively threaded system, all such contentions can be handled via thread priorities. Complex systems start getting stick when you need to provide guaranteed response to two or more equally critical tasks, but if you need that, you probably need two or more processors as well. One necessity that will happen shortly after providing a pervasively threaded system is the need for a tool to view the interactions of the threads and their priorities at a high level. Any idea that we can get along without one should be erased from your minds now. Since a picture is worth a thousand words, look at http://www.windriver.com/products/html/windview2_ds.html for an example of the type of tool I'm failing to describe. In particular, the "Screen 2" image. > > 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. In fact, it would be possible to create a special scheduling entity for fast interrupt response on processors like SPARC in which only one or two register windows are opened. This would be adequate for an interrupt task that simply transfers data from a device to memory or vice versa, then returns, like a serial port driver. It's such a good idea I'm now disappointed Wind River hasn't implemented it. ;^) > > 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 more specifically > those from BSDI who have experience with the actual implementation. Talking to people with real experience in the task at hand is rarely a bad idea. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message