From owner-freebsd-hackers Thu Aug 9 10: 5:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.dis.org (mass.dis.org [216.240.45.41]) by hub.freebsd.org (Postfix) with ESMTP id 4958137B403; Thu, 9 Aug 2001 10:05:22 -0700 (PDT) (envelope-from msmith@mass.dis.org) Received: from mass.dis.org (localhost [127.0.0.1]) by mass.dis.org (8.11.4/8.11.3) with ESMTP id f79H8Xq01162; Thu, 9 Aug 2001 10:08:33 -0700 (PDT) (envelope-from msmith@mass.dis.org) Message-Id: <200108091708.f79H8Xq01162@mass.dis.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: tlambert2@mindspring.com Cc: Greg Lehey , void , freebsd-hackers@FreeBSD.org Subject: Re: Allocate a page at interrupt time In-reply-to: Your message of "Thu, 09 Aug 2001 03:13:58 PDT." <3B726266.8026211C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 10:08:32 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > I really can't buy the idea that interrupt threads are a good > idea for anything that can flood your bus or interrupt bandwidth, > or have tiny/non-existant FIFOs, relative to the speeds they are > being pushed; right now that means "might be OK for disks; not OK > for really fast network controllers, not OK for sorta fast network > controllers without a lot of adapter RAM, not OK for serial ports > and floppies", at least in my mind. The basic problem here is that you have decided what "interrupt threads" are, and aren't interested in the fact that what FreeBSD calls "interrupt threads" are not the same thing, despite being told this countless times, and despite it being embodied in the code that's right under your nose. You believe that an interrupt results in a make-runnable event, and at some future time, the interrupt thread services the interrupt request. This is not the case, and never was. The entire point of having interrupt threads is to allow interrupt handling routines to block in the case where the handler/driver design does not allow for nonblocking synchronisation between the top and bottom halves. Most of the issues you raise regarding livelock can be mitigated with thoughtful driver design. Eventually, however, the machine hits the wall, and something has to break. You can't avoid this, no matter how you try; the goal is to put it off as long as possible. So. Now you've been told again. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message