Date: Sun, 18 Mar 2001 19:18:04 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Warner Losh <imp@harmony.village.org> Cc: John Baldwin <jhb@FreeBSD.ORG>, Matthew Jacob <mjacob@feral.com>, arch@FreeBSD.ORG Subject: Re: man pages t Message-ID: <Pine.BSF.4.21.0103181841310.27057-100000@besplex.bde.org> In-Reply-To: <200103180723.f2I7NY948714@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 18 Mar 2001, Warner Losh wrote: > In message <Pine.BSF.4.21.0103181501580.25882-100000@besplex.bde.org> Bruce Evans writes: > : This is a good bad example. It's too late to disable interrupts in the > : interrupt handler, because the handler might not be called until long > : after the hardware asserts an interrupt (a delay of 20 msec is not > : impossible, especially in -current). > > Even for fast interrupts? On other hardware for the job I have now we > see indications that 20ms might not be unreasonable a delay (we have > interrupts going off 22x a second, which is really more like 45ms, and > we seem to be missing interrupts on a heavily loaded system). It's not nearly that bad for fast interrupts, even in -current. An interrupt latency of 20 usec is a more normal worst case in -current (it depends on the CPU and load). But in RELENG_4 the worst case is more like 2 usec provided there are no competing fast interrupts. I'm seeing large latencies for non-fast interrupts being caused by ata interrupt activity. I don't really understand them. ithread priorities should prevent them (at least for ithreads with priority higher than the ata ithread. Of course there will be very large latencies for lower priority ithreads, especially for ata drives that can't do DMA). > : In your example, if missing the window would be fatal, to work under > : FreeBSD you need to use a fast interrupt handler under FreeBSD-4.x > : or better (fast interrupt handlers are broken in -current), and > : arrange for all other fast interrupt handlers combined to not break > : the window (this probably involves not having any other active ones). > > I use a fast interrupt handler :-). I thought that disabling all > interrupts kept even other fast interrupt handlers from running. And > that was the difference between splhigh() and disable_intr(). Then the handler will start with interrupts disabled, so no interrupt disablement is necessary. It shouldn't call splhigh()/splx() anyway (NO functions may be called from fast interrupt handlers :-). In practice, calling splhigh() is harmless but calling splx() could cause panics and other problems. It's the other parts of the driver that need to disable interrupts explicitly. They really just want to lock out the fast interrupt or duplicate the environment of the fast interrupt handler (so that they can do the things that the handler does, perhaps by calling it directly). The thread that we started from is mostly about doing this less hackishly. The locking aspects are too tangled up with interrupts and other voodoo. > The window is actually fairly large to get things going (something on > the order of 500 longwords in the fifo, which gives a latency of > something like 5ms since the frames come in every 33ms (60 fields a > second is 30 frames a second and the data is squirted out such that > 500 longwords is just under 5ms of data). We had all kinds of > problems with 4.0 and non-fast interrupts on slow machines. On fast > (600MHz+) machines we could likely get away with non-fast interrupts, > but I haven't bothered to recode it since those are the only CPUs that > the client can obtain for the boards in question (don't ask me why, I > long since gave up trying to argue with them). The not-so fast interrupts in current are adequate for a laency of 5msec. I think splhigh() would have been plenty in RELENG_4, and your problem there was that splhigh() is not really a driver interface. Normal (non-clock) drivers have to have type bio, cam, net or tty and the spls for those are not high enough. > : If missing the windows wouldn't be fatal, then just use a normal > : interrupt handler and recover from errors. Fast interrupt handlers > : are too hard to use to use routinely. > > Agreed. They should be easier. But with enough patience and skill, > they can be used when you gotta have the response time. I've found > that fast interrupts work out best when you have just a circular > buffer of stuff and you don't need to do selwake from the interrupt > handler (I'm not even sure you are allowed to do selwake from a fast > interrupt handler). Right, you are not allowed to call ANY functions from a fast interrupt handler :-). An ideal fast interrupt handler does little more than `buf[bufindex++ & MASK] = inb(PORT);' Bruce 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?Pine.BSF.4.21.0103181841310.27057-100000>