Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Oct 2002 06:45:35 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Don Bowman <don@sandvine.com>, "'Kenneth P. Stox'" <stox@imagescape.com>, FreeBSD current users <current@FreeBSD.ORG>
Subject:   Re: RE: Dedicating an interrupt to a PC-Card slot
Message-ID:  <20021018062749.W12183-100000@gamplex.bde.org>
In-Reply-To: <200210171815.g9HIFX3a022794@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Oct 2002, Matthew Dillon wrote:

> :Doesn't sound like that fast an interrupt. The 16550 has a 16-byte
> :send and receive fifo. Set the rx interrupt @ 14, and the tx @ 2.
> :230400/8 = 28800 chars /s
> :28800 / 14 = 2057 interrupts / s. This should be well within reach
> :of a pentium-class machine.
>
>     Not a good idea.  If you set the rx fifo at 14 you will get fewer
>     interrupts, sure, but you will also have less of a safety margin to
>     process them before the rx fifo potentially overflows and you lose
>     characters.  This is why I changed the default fifo level from HIGH (14)
>     to MEDH (8) a while back.

I still disagree with this change in -current.

>     In anycase, anything less then 10,000 interrupts a second ought to be
>     fine.  The real problem is still going to be other things in the system
>     causing enough interrupt latency to result in lost characters.  The most
>     common culprit is X windows doing big bitblits to the video card /
>     video memory, and I think having a non-DMA IDE interface can also cause
>     problems.

The real problems are probably fatal in -current, since the worst-case
interrupt latency is many milliseconds (e.g., for mii_tick()) and this
affects most non-fast interrupt handlers including siointr() in non-fast
mode because they are blocked by Giant.  mii_tick() causes a similar
amount of latency in RELENG_4, but this only affects timeout routines
because interrupt priorities actually work in RELENG_4, at least in the
non-SMP case.

Non-DMA for IDE causes no problems for fast interrupt handlers, but
DMA does.  Non-DMA for IDE causes much the same Giant locking problems
in -current as mii_tick() (but smaller).  In RELENG_4, it causes latency
problems for most interrupt handlers except tty ones.

Try the following change to prevent siointr() being blocked by Giant.
This is untested, but should work, since siointr() works as a fast
interrupt handler and fast interrupt handlers aren't blocked by Giant.

%%%
Index: sio.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/sio/sio.c,v
retrieving revision 1.382
diff -u -2 -r1.382 sio.c
--- sio.c	11 Oct 2002 20:22:20 -0000	1.382
+++ sio.c	17 Oct 2002 20:18:53 -0000
@@ -1117,5 +1146,6 @@
 		if (ret) {
 			ret = BUS_SETUP_INTR(device_get_parent(dev), dev,
-					     com->irqres, INTR_TYPE_TTY,
+					     com->irqres,
+					     INTR_TYPE_TTY | INTR_MPSAFE,
 					     siointr, com, &com->cookie);
 			if (ret == 0)
%%%

Unfortunately, for this to work well, you need non-shared-interrupts
or only very lightweight interrupts that are not blocked by Giant
sharing the irq.  This means no (active) sharing in practice, so it
may be as hard to configure as no sharing at all.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021018062749.W12183-100000>