On 2017-06-12 15:48:49 [+0200], Niels Kolthoff wrote: > Hi, > > I'm currently testing a RT application that communicates with sensor > hardware using a tty serial port. The application polls the tty port > (non-blocking) in a user space thread (priority 80) for incoming data. > On a raspberry PI3 (ttyAMA0), with kernel 4.4.9-rt17, response times < > 650usec are achieved, which is fine. > > Any version equal or above 4.4.12-rt20 will increase response peaks to > (about 0.1%) > 2msec, with some peaks > 5msec. > > cyclictest doesn't reproduce this, so I suspected a change in the tty > driver, or related to raspberry pi. > > I found that, by reverting the attached patch, response times return > to < 650usec. I suspect it has something to do with a change in the > read poll. > > I'd like to help solving this issue, can anyone give me some pointers > on how to continue? My guess is that the newly introduced tty_buffer_flush_work() waits until all in-kernel data is processed before returning -EAGAIN (if the buffer is empty) for the non-blocking case which unbreaks ssh. So this wait could blocking you for longer than required. If that is really it, then this is what could be optimized :) > Regards, > Niels Kolthoff Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
