From owner-freebsd-arch Tue Jul 18 20:23:43 2000 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id F121337BAB5; Tue, 18 Jul 2000 20:23:33 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA89215; Tue, 18 Jul 2000 21:23:32 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id VAA76910; Tue, 18 Jul 2000 21:23:23 -0600 (MDT) Message-Id: <200007190323.VAA76910@harmony.village.org> To: Greg Lehey Subject: Re: Tidying up the interrupt registration process Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG In-reply-to: Your message of "Mon, 17 Jul 2000 16:30:38 +0930." <20000717163038.J26231@wantadilla.lemis.com> References: <20000717163038.J26231@wantadilla.lemis.com> Date: Tue, 18 Jul 2000 21:23:23 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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