On Wed, Jan 26, 2022 at 09:52:26AM +0100, Greg Kroah-Hartman wrote:
>
> Let me revert this for now. And no new config options please, this
> should "just work".
I'm not sure the commit is actually worth the extra complexity, to be
honest. The reason for the FIFO is to improve interrupt latency, and
in the console write path, we're busy looping. There is something
seriously wrong serial port of the HP Proliant DL380 Gen 9. Per the
commit description for 5021d709b31b: ("tty: serial: Use fifo in 8250
console driver"), on the "fast machine" (read: the one with a
propertly working serial port), we were getting over 10 KB/s without
the patch. And on the "slow machine" it was getting only 2.5 KB/s,
and with the patch it only improved things by 25% (so only 3.1 KB/s).
I assume what must be going on is this machine is emulating the UART
and is extremely slow to set the Trasmitter Holding Register Empty
(THRE) bit after the UART is finished sending the byte out the serial
port.
So we're adding a lot of complexity for what is obviously broken
hardware, and we risk breaking the serial console for other machines
with a properly implemented serial port. How common are UART's which
are broken in this way? Is it unique to the HP Proliant DL380 Gen 9?
Or is a common misimplementation which is unfortunately quite common?
If it's the former, maybe the FIFO hack should only be done via a
quirk?
If it's really the case that the HP Proliant's nasty performance is
due to a badly implemented emulation layer, is there any way to do
better, perhaps via a more direct path to the serial port? Or is the
problem that the serial port on this motherboard is connected via some
super-slow internal path and it would be faster if you could talk to
it directly via a UEFI call, or some other mechanism? Whether it's
2.5 KB/s or 3.1 KB/s, it's really quite pathetic....
- Ted
