On 05.01.2022 11:37, Greg Kroah-Hartman wrote: > On Wed, Jan 05, 2022 at 08:59:09AM +0100, Tomasz Moń wrote: >> 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. > > Yes, Linux can be used in real time situtations just fine, look at the > RT patchset for proof of that. > > So let's not make things any worse for no good reason if at all > possible. Avoiding interrupt storm is a good reason for me. >> 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. > > If this can't be measured at all, why make this change in the first > place? It can be measured, just in general case, it is hard to tell exactly how much does it help due to the complexity. All the time saved by not wasting it in interrupt handler can have impact on many parts of the system. However, there is a use case where it is easy to tell how much does this change improve performance. In the situation where the interrupt storm occurs with current mainline kernel (RXTL is set to 1) essentially freezing everything until the sender stops transmitting, the patched kernel (with RXTL is set to 8) handles the situation just fine. Change from completely unresponsive to just fine is easy to notice. Best Regards, Tomasz Mon
