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

[phoronix]

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

It's not an area of Linux hardware performance we normally look at, but thanks to a Red Hat engineer discovering very low serial console performance, there is an improvement queued up for introduction in Linux 5.17.....

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Serial-16550-FIFO

[Alex/AT]

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.

[JEBjames]

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.

Michael typo: "cosnole"

[Alex/AT]

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

Basically this means controller is sending bytes faster than polling sender can feed it.
It's not polling in a tight loop, it's rescheduled. And the poller is not scheduled in intervals short enough on specific machine it seems.

OR the UART (or its emulation by i.e. BMC) is so crazy that it doesn't bring the related 'buffer empty' bit to 'empty' state immediately after transmitting the buffered byte, like nobody ever expected someone no less crazy would be sending stuff at high speeds without FIFO in polling mode

[onlyLinuxLuvUBack]

Basically this means controller is sending bytes faster than polling sender can feed it.
It's not polling in a tight loop, it's rescheduled. And the poller is not scheduled in intervals short enough on specific machine it seems.

OR the UART (or its emulation by i.e. BMC) is so crazy that it doesn't bring the related 'buffer empty' bit to 'empty' state immediately after transmitting the buffered byte, like nobody ever expected someone no less crazy would be sending stuff at high speeds without FIFO in polling mode

a phoronix bar chart and benchmark will settle this

[jabl]

Wonder if this would affect 'virtual' serial ports as well, as commonly seen on server platforms where you have a virtual serial console accessible via the BMC? Or is it only for 'real' hardware UART chips?

[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.

[JEBjames]

a phoronix bar chart and benchmark will settle this

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

https://xkcd.com/688/

[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..

[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.