Linux Serial Console Driver Lands Patch For Possible ~25% Performance Improvement

[mlau]

16550 UARTs FIFO support was missing all that time?
Holy moly. I thought it's 2022 already, but it's more like 1982 there then.

No. What was missing was FIFO handling of the serial console codeparts in the 8250 driver. Up until this change, the 8250 serial console just put 1 byte into the tx fifo and waited until it was sent to put in the next one.

[discordian]

The UART FIFO queue can reduces CPU load (fewer interrupts). But even pre-486 PCs can easily max out a 16550 sending a byte at a time?

Not sure how it could make that big a speed difference as quoted in the article?

Task switching that broken? Insert Spectre/Meltdown/RandomCPUBugOfTheWeek?

I'm confused.

Typically you write to registers that sit on a really really slow bus, or even worse you need to poll if you can write (effectively giving your CPU i486 era speed). One access can easily take some microseconds, which is forever on current systems, so meanwhile other interrupts/work will be queued and you swap around processes and irq handlers frequently.
This is not limited to UARTS, some modern hardware like Intel's i210 network controllers have this behavior as well. You need to use DMA or things come to a crawl.

[jabl]

This are the oldest devices around, from the time of 486's, Pentiums, or newer, by other word's...obsolete

Nowadays, the buffers are superior to 1KB, I believe, but it will depend on the hardware you have..

Per wikipedia, the 16550 was originally introduced in 1987, which was actually before the 486. That being said, they are still around. Not in the original form, but some tiny speck of dust in the corner of the system chipset that emulates the original device. So still limited by the 16 byte buffer. On my laptop (that doesn't even have a rs-232 port):

$ dmesg|grep ttyS
[ 2.332159] 0000:00:16.3: ttyS4 at I/O 0x3060 (irq = 19, base_baud = 115200) is a 16550A
[ 69.425124] dw-apb-uart.1: ttyS5 at MMIO 0x604110f000 (irq = 20, base_baud = 115200) is a 16550A

[Quackdoc]

I think serial will probably be one of the few things that will never die in the tech world

[jabl]

Just to note, the guy was trying to run at 115200, which was getting less throughput on a 'slower' machine, but working as expected on a 'faster' machine. To put that in perspective, most actual serial terminals were lucky to run at 9600, and the most you could pump out the telephone wires (ignoring compression) was 57600. Personally, the hardest I generally drove serial ports was for dial-up modems, and of course for actual consoles and printers much slower speeds were used, so its not too suprising that not many people would have noticed this... I have an actual DEC vt320 hooked up to my machines serial port as a console, and you can configure that to run at 19200, but the terminal itself cannot actually keep up with text at that speed, so I run it at 9600. (It might be able to process SIXEL data at the higher speed... I should try that.)

The 'slower' machine he tested was a Xeon Haswell based system. Not the latest and greatest, but not ancient history either. I have to admit that based on the patch description I don't understand what the pertinent difference between the two systems he tested on are, but I'd suspect it's some quirk related to the particular model of UART chip used.

I've got plenty of experience watching server systems boot over the virtual serial console, and lemme tell you, if you forget to change from the default 9600 it's SLOWW. (though as I mentioned in another comment in this thread, I don't know if this change affects virtual serial consoles or only 'real' ones).

[foobaz]

Coming soon from Phoronix:
- AMD vs Intel serial console shootout
- ZMODEM transfer benchmarks in the Phoronix Test Suite
- Effects of compiler optimization flags on VT220 performance
- GCC 11 vs. GCC 12 for serial port performance - should you upgrade?!

[GI_Jack]

16550 UARTs FIFO support was missing all that time?
Holy moly. I thought it's 2022 already, but it's more like 1982 there then.

I am going to guess. Linux started out as a grad-student project in 1989, and was kinda flaky and missing a lot of features, especially hardware support for the first decade of its life. By the time it got going, no one really cared about UART anymore, and most serial consoles aren't performance intensive, as its the last thing anyone generally uses for sending large amount of data, and USB, ethernet, bluetooth all became well maintained.

Until now, someone has a usecase for sending high volume RS-232 serial data in 2022, that has performance needs, interesting.

[tuxd3v]

Afaik,
The 16550A (or 16550, as its called) FIFO has 16 byte FIFO buffers.
It can receive up to 14 bytes (or send 16 bytes) before it has to interrupt the CPU.
This are the oldest devices around, from the time of 486's, Pentiums, or newer, by other word's...obsolete

Nowadays, the buffers are superior to 1KB, I believe, but it will depend on the hardware you have..

[JEBjames]

a phoronix bar chart and benchmark will settle this

There is a 50% chance this chart answers the question.

https://xkcd.com/688/

[jabl]

But even pre-486 PCs can easily max out a 16550 sending a byte at a time?

I think interrupt latency is one those (few) things that hasn't really improved much since the 486 days. Doesn't really matter that a modern CPU can shovel stuff orders and orders of magnitude faster than a 486, if the interface only allows copying a single byte between each interrupt.