Messages in this thread | | | Date | Tue, 25 Jan 2022 10:08:36 +0100 | Subject | Re: [PATCH] tty: serial: Use fifo in 8250 console driver | From | Jiri Slaby <> |
| |
On 25. 01. 22, 9:39, Jon Hunter wrote: > > On 29/10/2021 21:14, wander@redhat.com wrote: >> From: Wander Lairson Costa <wander@redhat.com> >> >> 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@redhat.com> > > > 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.
The test is bogus: use_fifo = (up->capabilities & UART_CAP_FIFO) && port->fifosize > 1 && (serial_port_in(port, UART_FCR) & UART_FCR_ENABLE_FIFO)
FCR is write only. Reading it, one gets IIR contents.
regards, -- js suse labs
| |