Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Dec 2001 22:42:50 -0500 (EST)
From:      Mike Silbersack <silby@silby.com>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        Matt Dillon <dillon@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/dev/sio sio.c
Message-ID:  <Pine.BSF.4.30.0112222227020.56560-100000@niwun.pair.com>
In-Reply-To: <20011223135146.H10320-100000@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sun, 23 Dec 2001, Bruce Evans wrote:

> On Sat, 22 Dec 2001, Mike Silbersack wrote:
>
> > Is there real harm in using more frequent interrupts?
>
> It increases overhead a little.

True.

> > If no, then Matt's change should be left in.
> >
> > If yes, explain why.  References to old hardware are not relevant - the
> > performance of 4.5-prerelease on modern hardware are.
>
> More frequent interrupts mainly hide interrupt latency problems.  If
> something breaks interrupt latency, then there is nothing to prevent
> it from being broken by twice as much.
>
> Note that there is a problem if you have more than about 8 active sio
> devices or similar devices on other drivers that use fast interrupt
> handlers (currently, the cy serial driver is the only other driver
> with non-broken fast interrupt handlers).  The devices will get in
> each others way.
>
> The driver used to have dynamic fifo trigger reduction, mainly to
> support many active sio devices, but this was found harmful and backed
> out:

Well, the change is from triggering at 14/16 to 8/16, so we're actually
gaining 6 bytes of buffering, allowing us 4x as long to respond.  (If I'm
reading 16550A trigger level explanations correctly.)

I'm not sure how to address the situation with lots of sio interfaces;
that sounds like an uncommon case, and I don't think it should drive the
default configuration of our serial driver.

Interrupt latency may be the fault of other subsystems, and in a perfect
world I'm sure we wouldn't have that problem.  However, since the problem
does exist (and isn't going away), it seems wise to just bite the bullet
and change the trigger level.  Users aren't going to care what the trigger
level is, and those few that care can make a local change and recompile
their kernel.  Users will simply be happy that after this change their
serial ports do not drop characters.

Mike "Silby" Silbersack



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" 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.30.0112222227020.56560-100000>