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?
Correct
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.
Best regards,
-- Sergey Organov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
