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