linux-kernel - Re: [RFC 2/2] serial/8250.c: Use self-adjusting list for port poll order.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20081116152352.20261.qmail@science.horizon.com>
Date:	Sun, 16 Nov 2008 10:23:52 -0500
From:	"George Spelvin" <linux@...izon.com>
To:	tytso@....edu, alan@...rguk.ukuu.org.uk
Cc:	linux@...izon.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/2] serial/8250.c: Use self-adjusting list for port poll
 order.

Theodore Tso <tytso@....edu> wrote:
> On Fri, Nov 14, 2008 at 09:47:11PM +0000, Alan Cox wrote:
>>> This code does that by using the previous poll cycles as a hint.
>>> If a port is idle, it will migrate to the end of the list and
>>> only have to be checked once.
>> 
>> Is it really worth the complexity?
>> 
>> - PCI ports are shared IRQ always
>> - Legacy ports are almost never shared IRQ on the LPC bus (and are
>> increasingly going away)
>
> It's worth the complexity only *if* you have enough ports shared on a
> single IRQ and simultaneously such that there a risk that if you don't
> poll them quickly enough, characters will actually get dropped from
> the UART's FIFO.  The question is whether that is likely to happen on
> modern CPUs.  I worred about such things when I tried to make 16
> 115kbps serial ports work at full-speed using relatively primitive
> 16550A UARTs with 16 character FIFOs on a 40 MHz 386.  But (a)
> UARTs generally have deeper FIFOs these days, and (b) CPUs have
> gotten a wee bit faster since 1992.
>
> So color me dubious that this is actually necessary....

First of all, thank you both for the feedback.

Re: shared IRQs and PCI bus...
In desktop hardware, yes.  But PC-104 equipment (for the benefit of
confused bystandaers, that's classic ISA bus in a different form factor)
is still going strong; I just added an 8-port serial card to a little
embedded box.

But even PCI reads are slow, and the current code does not optimize the
case when interrupts are level-sensitive.  (The optimization is trivial,
but detecting whether the interrupt is edge- or level-sensitive looks
messy.)

Regarding the purpose of the patch...
The goal is not fewer dropped characters (although there could be a small
benefit in that direction), and it doesn't improve worst-case timing;
the goal is to reduce the time spent in the interrupt handler _on average_
and thereby make more CPU available for other work.

The idea is that, if you have 4 ports sharing an interrupt, and the fourth
is the one that's busy, you'll check every port twice.  If you could check
the busy port first, you'd only need to to do 5 checks.

The real over-optimization argument that I can think of is that emptying 8 bytes
out of a FIFO involves 16 register reads (LSR + receive data for each byte),
compared to which the time to poll a few IIRs is not too much.  (Of course, then
there's low_latency mode.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/