Re: tty_flip_buffer() from atomic context when low_latency==1

[Grant Edwards <grant.b.edwards@gmail.com>]

On 2011-08-19, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> 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