From owner-freebsd-arch Tue Jul 18 23:13:32 2000 Delivered-To: freebsd-arch@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 8624B37BCD6; Tue, 18 Jul 2000 23:13:22 -0700 (PDT) (envelope-from grog@wantadilla.lemis.com) Received: (from grog@localhost) by wantadilla.lemis.com (8.9.3/8.9.3) id PAA73758; Wed, 19 Jul 2000 15:43:13 +0930 (CST) (envelope-from grog) Date: Wed, 19 Jul 2000 15:43:13 +0930 From: Greg Lehey To: Warner Losh Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <20000719154313.M12072@wantadilla.lemis.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200007190558.XAA77880@harmony.village.org> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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