Date: Wed, 19 Jul 2000 15:43:13 +0930 From: Greg Lehey <grog@lemis.com> To: Warner Losh <imp@village.org> Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719154313.M12072@wantadilla.lemis.com> In-Reply-To: <200007190558.XAA77880@harmony.village.org> References: <20000719130907.H12072@wantadilla.lemis.com> <20000717163038.J26231@wantadilla.lemis.com> <200007190323.VAA76910@harmony.village.org> <20000719130907.H12072@wantadilla.lemis.com> <200007190558.XAA77880@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 18 July 2000 at 23:58:43 -0600, Warner Losh wrote:
> In message <20000719130907.H12072@wantadilla.lemis.com> Greg Lehey writes:
>> I think this function needs to be completely rewritten in the course
>> of the implementation of interrupt threads. It sort of works now, so
>> I don't think we should touch it further until the threads are up and
>> hobbling.
>
> I want to fix the fast interrupt part of it.
Well, I was lying when I said we wouldn't touch it. In the meantime,
I've seen that the BSDi implementation has already addressed the
question of priorities, and now we have no more interrupt masks, the
mask parameter to inthand_add changes into a pri parameter. So the
code you're talking about becomes:
switch (flags) {
case INTR_TYPE_TTY:
pri = PI_TTYLOW;
break;
case (INTR_TYPE_TTY | INTR_FAST):
pri = PI_TTYHIGH;
break;
The flags parameter also gets passed directly to inthand_add.
>> That's what I thought. Does anybody else see a reason to convert fast
>> interrupts into threads?
>
> So long as they run with the lowest possible latency, that would be
> OK.
See the discussion. It won't work like that.
>>> pci modems are an interesting problem. You want to share an
>>> interrupt, but fast interrupts can't be shared. On sufficiently
>>> fast machines, it isn't an issue, but on slow machines you can
>>> easily lose characters because interrupts are masked for too long.
>>> Heavy VM load (eg swapping) seems to make this problem happen more
>>> often than even just simple heavy disk I/O, but I've not done
>>> extensive tests to draw boundaries around this problem.
>>
>> 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.
>
> I think it is an implementation thing, but bde will know better.
He's been very quiet lately.
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?20000719154313.M12072>