Date: Tue, 18 Jul 2000 21:23:23 -0600 From: Warner Losh <imp@village.org> To: Greg Lehey <grog@lemis.com> Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Tidying up the interrupt registration process Message-ID: <200007190323.VAA76910@harmony.village.org> In-Reply-To: Your message of "Mon, 17 Jul 2000 16:30:38 %2B0930." <20000717163038.J26231@wantadilla.lemis.com> References: <20000717163038.J26231@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20000717163038.J26231@wantadilla.lemis.com> Greg Lehey writes: : I think I now understand how drivers register interrupts with newbus, : and it seems that some tidying up is in order. Yes. : 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. : It seems to me that we should define the flags to the *setup_intr : functions to match those in struct intrec. Probably the RF_* flags : are different enough in purpose that we shouldn't do the same thing : there. I think that INTR_FAST is special enough to be the only one that needs help. : 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. : 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. 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. Warner 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?200007190323.VAA76910>