Hi Sergey,
Am 17.04.23 um 18:50 schrieb Sergey Organov:
Hi Stefan,
Stefan Wahren <stefan.wahren@xxxxxxxx> writes:
Hi Sergey,
[...]
i had some time today to investigate this a little bit. I thought it
would be a good idea to use debugfs as a ugly quick hack:
[...]
Using this i was able to better compare the behavior with RXTL_DEFAULT
1 (without overrun errors) and RXTL_DEFAULT 8 (with overrun errors) on
my i.MX6ULL test platform. After doing my usual test scenario (copy
some text lines to console) i got the following results:
RXTL_DEFAULT 1
21f0000.serial/stats:total_duration_us: 61
21f0000.serial/stats:rx_duration_us: 36
21f0000.serial/stats:tx_duration_us: 48
21f0000.serial/stats:received: 28
21f0000.serial/stats:send: 33
RXTL_DEFAULT 8
21f0000.serial/stats:total_duration_us: 78
21f0000.serial/stats:rx_duration_us: 46
21f0000.serial/stats:tx_duration_us: 47
21f0000.serial/stats:received: 33
21f0000.serial/stats:send: 33
So based on the maximum of received characters on RX interrupt, i
consider the root cause of this issue has already been there because
the amount is near to the maximum of the FIFO (32 chars). So finally
increasing RXTL_DEFAULT makes the situation even worse by adding
enough latency for overrun errors.
Yep, looks like an issue.
What's the baud rate? 115200? If so, it means that interrupts are
apparently blocked in your system for up to about 28/(115200/10)=2.4
milliseconds. This is very large number, and it may negatively affect
system performance in other places as well, I'm afraid.
i forgot to mention that i also measured the time around
printk_safe_(enter|exit)_irqsave in console_emit_next_record() which had
a maximum of 24721 µs. But uncommenting these functions doesn't fixed
the problem. This seems to be used only by printk.
Best regards
Best regards,
-- Sergey Organov
