Date: Sat, 15 Apr 2000 09:12:10 -0600 From: Wes Peters <wes@softweyr.com> To: Julian Elischer <julian@elischer.org> Cc: Terry Lambert <tlambert@primenet.com>, Kirk McKusick <mckusick@flamingo.McKusick.COM>, Poul-Henning Kamp <phk@freebsd.org>, arch@freebsd.org Subject: Re: BUF/BIO roadmap. Message-ID: <38F886CA.A1E99CDE@softweyr.com> References: <200004111649.JAA17290@usr01.primenet.com> <38F35AC2.237C228A@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38F886CA.A1E99CDE>