Re: [PATCH] tty: serial: Use fifo in 8250 console driver
From: Jon Hunter
Date: Tue Jan 25 2022 - 04:15:44 EST
On 25/01/2022 08:50, Greg Kroah-Hartman wrote:
On Tue, Jan 25, 2022 at 08:39:24AM +0000, Jon Hunter wrote:
On 29/10/2021 21:14, wander@xxxxxxxxxx wrote:
From: Wander Lairson Costa <wander@xxxxxxxxxx>
Note: I am using a small test app + driver located at [0] for the
problem description. serco is a driver whose write function dispatches
to the serial controller. sertest is a user-mode app that writes n bytes
to the serial console using the serco driver.
While investigating a bug in the RHEL kernel, I noticed that the serial
console throughput is way below the configured speed of 115200 bps in
a HP Proliant DL380 Gen9. I was expecting something above 10KB/s, but
I got 2.5KB/s.
$ time ./sertest -n 2500 /tmp/serco
real 0m0.997s
user 0m0.000s
sys 0m0.997s
With the help of the function tracer, I then noticed the serial
controller was taking around 410us seconds to dispatch one single byte:
$ trace-cmd record -p function_graph -g serial8250_console_write \
./sertest -n 1 /tmp/serco
$ trace-cmd report
| serial8250_console_write() {
0.384 us | _raw_spin_lock_irqsave();
1.836 us | io_serial_in();
1.667 us | io_serial_out();
| uart_console_write() {
| serial8250_console_putchar() {
| wait_for_xmitr() {
1.870 us | io_serial_in();
2.238 us | }
1.737 us | io_serial_out();
4.318 us | }
4.675 us | }
| wait_for_xmitr() {
1.635 us | io_serial_in();
| __const_udelay() {
1.125 us | delay_tsc();
1.429 us | }
...
...
...
1.683 us | io_serial_in();
| __const_udelay() {
1.248 us | delay_tsc();
1.486 us | }
1.671 us | io_serial_in();
411.342 us | }
In another machine, I measured a throughput of 11.5KB/s, with the serial
controller taking between 80-90us to send each byte. That matches the
expected throughput for a configuration of 115200 bps.
This patch changes the serial8250_console_write to use the 16550 fifo
if available. In my benchmarks I got around 25% improvement in the slow
machine, and no performance penalty in the fast machine.
Signed-off-by: Wander Lairson Costa <wander@xxxxxxxxxx>
On the current mainline and -next branches, I have noticed that the
serial output on many of our Tegra boards is corrupted and so
parsing the serial output is failing.
Before this change the serial console would appear as follows ...
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd071]
[ 0.000000] Linux version 5.16.0-rc6-00091-gadbfddc757ae (jonathanh@jonathanh-vm-01) (aarch64-linux-gnu-gcc (Linaro GCC 6.4-2017.08) 6.4.1 20170707, GNU ld (Linaro_Binutils-2017.08) 2.27.0.20161019) #15 SMP PREEMPT Tue Jan 25 00:15:25 PST 2022
[ 0.000000] Machine model: NVIDIA Jetson TX1 Developer Kit
And now I see ...
[ 0.000000] Booting Linux on physicalfd071]
[ 0.000000] Linux version 5.16.0-rc6-athanh@j-linux-g017.08) Linaro_B20161019n 25 00:[ 0.000000] Machine model: NVIDIA Jet[ 0.000000] efi: UEFI not found.
[ 0.000000] NUMA: No NUMA configurati[ 0.000000] NUMA: Faking a node at [m00000001[ 0.000000] NUMA: NODE_DATA [mem 0x17[ 0.000000] Zone ranges:
Bisecting is pointing to this commit. Let me know if there are any
tests I can run. Otherwise we may need to disable this at least
for Tegra.
Ick. Does this uart have any other quirks assigned to it that are
somehow not getting assigned here?
Not that I know of, but I can have a look. I did check to see if there
are any known issues that could be related but I have not found any so far.
Jon
--
nvpublic