On 2011-08-19, Alan Cox [off-list ref] wrote:

quoted

I don't understand why the low_latency flag even exists when setting
it apparently breaks most all of the serial drivers.

Mostly history. I'd not realised random users could fiddle with it - they
shouldn't be able to do that so that wants fixing.

Historically it made sense as with a 100Hz clock some algorithms with
drivers that delayed stuff a lot got really slow (eg non windowed
versions of firmware download protocols, kermit, xmodem etc)

I know why it used to be there, and "back in the day" setting it made
a very noticable difference in the latency on the receive data path.
In some situations, setting the low_latency flag could increase by a a
factor of 10 the number of command/reply transactions you could do per
second (particularly at high baud rates and commands/repsonses are
only a couple bytes).

Nowdays the kernel is a bit more sophisticated and we should possibly
re-arrange it so that it selects different workqueues or similar -
low_latency meaning 'use a private hard rt work queue' perhaps.

Or indeed possibly making ttys use threaded IRQs

For most of the drivers I'm maintaining, I've decided I'm going to
have to force low_latency = 0.  There is one driver that has one mode
where the receive data is handled in a non-atomic context, so that one
can still honor the low_latency flag, but the rest will have to force
it to 0.

[Why this only became a problem recently, I don't know.]

-- 
Grant Edwards               grant.b.edwards        Yow! Am I in Milwaukee?
                                  at               
                              gmail.com