Date: Wed, 19 Jul 2000 13:57:30 +0930 From: Greg Lehey <grog@lemis.com> To: Mike Smith <msmith@FreeBSD.ORG> Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719135730.J12072@wantadilla.lemis.com> In-Reply-To: <200007190403.VAA21389@mass.osd.bsdi.com> References: <20000719130907.H12072@wantadilla.lemis.com> <200007190403.VAA21389@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 18 July 2000 at 21:03:59 -0700, Mike Smith wrote: >>> The INTR_TYPE_TTY interrupts, except fast ones, are masked as a unit. >>> Likewise with the INTR_TYPE_NET, etc. The intent here is to provide >>> assistance in serialization of access to crititical structures. When >>> you do a splnet, all the net devices who have an interrupt have their >>> interrupt blocked. >> >> Right, that's the current way things are done. This will change too, >> to be replaced by relative scheduling priorities. That's the more >> interesting question: how should they relate to each other? > > As a general rule, they shouldn't. Don't get carried away with something > relatively trivial like which interrupts should have "more" scheduling > priority - just get them being scheduled at all for now. 8) That doesn't mean we shouldn't be thinking about the next step. >> I can't see anything inherent in the treatment of fast interrupts >> which says they can't be shared. I'll take another look at the code; >> maybe we can get rid of this restriction. > > Sharing a 'fast' interrupt completely defeats the point of making it > 'fast'. No, it partially defeats it. It's a tradeoff. > 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. 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 :-) Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?20000719135730.J12072>