linux-kernel - Re: How important is it that tty_write

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] [day] [month] [year] [list]

Message-Id: <83266FC1-CB6F-4FC6-AAD3-05EC006B553E@mit.edu>
Date:	Thu, 24 Feb 2011 07:34:00 -0500
From:	Theodore Tso <tytso@....EDU>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	Timur Tabi <timur@...escale.com>, Greg KH <gregkh@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: How important is it that tty_write_room doesn't lie?

On Feb 23, 2011, at 5:57 PM, Ted Ts'o wrote:

>> The FIFO can vary, but it's probably at least 2KB it size.  At
>> least, we hope to able to set it to that size in the field.
>> Currently, we set it to 4KB.
> 
> Wow, the FIFO has gotten a lot larger than I ever remember them
> getting even when people were doing 460kbps.  I'm guessing this is
> because you're trying to defer interrupts for power saving reasons,
> yes?  I was used to seeing FIFO sizes more in the 32-128 bytes, tops.  :-)

One more thought: If your FIFO is that large, you might want to consider
simply having the interrupt driver wake up a kernel thread, say when it
half full (to give the scheduler time to wake up and let the kernel thread
run), and dequeue the FIFO in a process context.

Or as an intermediate step, do the FIFO dequeue in a bottom-half
handler, where you'll at least be able to do memory allocations.

Don't assume that you have to empty the entire FIFO into a circular
buffer in an interrupt handler, just because that's what the 8250/16550
driver does.  It was designed that way because it had very small FIFO's,
but there are other ways that serial drivers can work.

One device driver I worked on, for the Comtrol Rocketport, was designed
for a very large number of ports (32-128 serial ports) and it had a single 
huge buffer shared between all of the ports, and once an interrupt
kicked things off, it was more efficient to simply be constantly pulling
things out of the buffer and dispatching it to the various tty ports,
and in practice it was faster and more efficient never to pull
the characters out in interrupt context, but instead use a polling
type system instead.

Think of it as a very early form of NAPI interrupt mitigation, but for
serial ports instead of high speed ethernet.  :-)

-- Ted

--
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/