Date: Wed, 19 Jul 2000 13:09:07 +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: <20000719130907.H12072@wantadilla.lemis.com> In-Reply-To: <200007190323.VAA76910@harmony.village.org> References: <20000717163038.J26231@wantadilla.lemis.com> <200007190323.VAA76910@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 18 July 2000 at 21:23:23 -0600, Warner Losh wrote: > In message <20000717163038.J26231@wantadilla.lemis.com> Greg Lehey writes: >> These flag bits are all lightly used, and there's confusing >> duplication of functionality. For example, in nexus_setup_intr we >> have: >> >> case (INTR_TYPE_TTY | INTR_TYPE_FAST): >> mask = &tty_imask; >> icflags |= INTR_FAST; > > This code is wrong. It should be moved out of the case statement. > BDE posted a fix that I thought I'd committed, but it appears that I > haven't done so yet. 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. >> In addition, these flags will have to change a lot in the change to >> threaded interrupts. First, I intend to add two additional flags to >> struct intrec: >> >> #define INTR_HEAVY 0x00000002 /* heavyweight interrupt process */ >> #define INTR_LIGHT 0x00000004 /* light weight interrupt thread */ >> #define INTR_THREADED (INTR_LIGHT | INTR_HEAVY) /* any kind of interrupt thread */ >> >> This will allow us to let traditional interrupts, lightweight threads >> and heavyweight processes to coexist; when the change is complete, we >> may be able to let them go away. The INTR_TYPE_TTY and friends are a >> different issue; at the moment I don't know if they're enough, but >> probably we should replace them with a process priority. I'd be >> grateful for any thoughts on these subjects. > > 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? >> About fast interrupts, which currently seem to be used only by the sio >> driver: they perform their entire work before reenabling interrupts, >> and it's possible that we can keep them like that, though I haven't >> looked at the code yet. Does anybody know any reason why we should >> convert them to threaded interrupts? > > Yes. They are used by more than the sio driver. I use them in at > least two pci drivers that I have written for hardware that has > extreme latency requirements that normal interrupts cannot > accomplish. This is the same sort of thing as the serial fifos. > These have extremely hard requirements to be serviced in (on the order > of micro seconds). The "upper half" of the serial driver harvests the > characters from the serial line when it gets interrupts and uses > splsofttty() to activate the lower half of the driver. These devices > simply cannot tolerate scheduling delays at all, even very fast ones. That's what I thought. Does anybody else see a reason to convert fast interrupts into threads? > 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. 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?20000719130907.H12072>