Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting for once, to make this easily accessible to everyone. Stefan, was this regression ever solved? It doesn't look like it, but maybe I'm missing something. If it wasn't solved: what needs to be done to get this rolling again? Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) -- Everything you wanna know about Linux kernel regression tracking: https://linux-regtracking.leemhuis.info/about/#tldr If I did something stupid, please tell me, as explained on that page. #regzbot poke On 18.04.23 18:16, Stefan Wahren wrote: > 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 > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
