From owner-freebsd-arch Tue Jul 18 21:41:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-177-51.dsl.snfc21.pacbell.net [63.202.177.51]) by hub.freebsd.org (Postfix) with ESMTP id 531AF37BC88; Tue, 18 Jul 2000 21:41:38 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.9.3/8.9.3) with ESMTP id VAA21651; Tue, 18 Jul 2000 21:49:32 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200007190449.VAA21651@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Greg Lehey Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process In-reply-to: Your message of "Wed, 19 Jul 2000 13:57:30 +0930." <20000719135730.J12072@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jul 2000 21:49:32 -0700 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > You should not be able to register a 'fast' handler on any source > > with anything else attached, nor anything else on a source that has > > a 'fast' handler already registered. Yes, this does impose some > > configuration constraints on the system, but there are few viable > > alternatives. > > You haven't really explained that. Sure, if you have more than one > interrupt on an IRQ, it will take longer, but it will still ensure > that nothing else interrupts in the meantime. You can't compare this > to the current fast interrupt scheme which limits you to one interrupt > handler, because the hardware reality isn't like that. You need to > compare it to the alternative of a shared slow interrupt handler: > clearly a fast interrupt handler will still be faster. And Warner > produced a valid example of where it would make a difference. This is not correct. There are two separate things that a 'fast' interrupt handler seeks to achieve: reduced and constrained interrupt latency. Allowing 'fast' interrupts to be shared removes any hope of constraining latency, as well as increasing it. Note also that a 'fast' handler may be computationally expensive - the 'fast' criterion has to do with how it is invoked, not how it runs. > As regards sharing fast and slow interrupts on the same IRQ: I can see > reasons for wanting to do this as well. I don't want to have to write > the code, though :-) It would be relatively trivial, actually, since the dispatcher that invokes the actual interrupt thread in the 'not-fast' case is really a 'fast' interrupt handler. -- ... 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] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message