On 04.01.2022 23:49, Uwe Kleine-König wrote: > On Tue, Jan 04, 2022 at 12:38:01PM +0100, Greg Kroah-Hartman wrote: >> On Tue, Jan 04, 2022 at 12:13:06PM +0100, Tomasz Moń wrote: >>> On 04.01.2022 11:54, Greg Kroah-Hartman wrote: >>>> Why can't you do this dynamically based on the baud rate so as to always >>>> work properly for all speeds without increased delays for slower ones? >>> >>> Could you please advise on which baud rates to consider as slow? Does it >>> sound good to have the old trigger level for rates up to and including >>> 115200 and the new one for faster ones? >> >> You tell me, you are the one seeing this issue and are seeing delays on >> slower values with your change. Do some testing to see where the curve >> is. While the increased latency due to this change is undeniable, it is important to note that latency is not everything. There are applications where the latency is crucial, however using Linux for such applications is questionable. Linux is not a Real Time Operating System after all. Latency is simple to measure and argue based on the reception of single character. That is only a corner case, not fully describing real world. In the real world, it is important to consider the overall performance improvement. It is hard to determine how much does the performance of the system improve thanks to less time spent in interrupt handling. > Maybe it's more sensible to make this even more dynamic: e.g. keep it at > 1 as default and increase the water level when a certain irq frequency > is reached? The more I think about this, the dynamic part feels less reasonable, i.e. all the extra complexity needed seems enormous compared to the potential advantage. I have hacked in a GPIO toggle at the end of interrupt handling. This allows me to measure the latency increase with the oscilloscope in the simple one character reception case. Latency here is defined as "time between the stop bit and GPIO toggle". Note that this test completely ignores the user space impact (process scheduling). With RXTL being set to 1 (aging timer effectively disabled), latency is within 10 to 20 us range. This time does not depend on the baud rate, but on the system, i.e. cpu frequency, memory layout, caching, compiler optimization level, other interrupts and so on. With RXTL being set to 8, baud rate set to 1M and 10 bits per character (8N1), latency is within 90 to 100 us range. The shift by approximately 80 us matches the expectations as it is directly induced by aging timer (interrupt was raised only after aging timer expired). When DMA is enabled, baud rate set to 1M and 10 bits per character (8N1), latency is within 100 to 110 us range. This is somewhat expected as the main latency contributing factor is the aging timer. The extra few us is likely due to the DMA overhead (not really important in real world where more than one byte is being transferred). Usually serial transmission happens in various length bursts (frames). For such transmissions the latency induced by the aging timer is generally equal to 8 characters time (when the frame length is exact multiple of RXTL there is no latency induced by the aging timer). Worst case scenario is when the intercharacter interval is slighly less than the aging timer timeout. While this is possible, in my opinion it is highly unlikely. Aging timer latency upper bound, mentioned in commit message, is equal to: (RXTL - 1) * (8 character time timeout + received 1 character time) The real advantage of higher RXTL is avoiding interrupt storm. With RXTL being set to 1, I am able to trigger interrupt storm at 1M and higher baud rates when intercharacter interval is virtually zero. This is expected because, as noted earlier, interrupt handling time is within 10 to 20 us range. As the interrupt handling time is more than the time it takes to transmit single character (10 us), this inevitably leads to line discipline workqueue starvation, and in turn to dropping the characters, because eventually: * tty flip buffer cannot take any more characters, * tty throttle does not happen due to interrupt storm, * RX interrupt is fast enough to keep RxFIFO below autoRTS level. With RXTL being set to 8, minimum RX interrupt period is 8 characters time. This happens when there is continuous data being received (no delay due to the aging timer). If changing the default RXTL value does not sound right, then maybe RXTL could be configured via a device tree property? That way it would be up to the user to tune it for the application. Best Regards, Tomasz Mon
