Re: locking changes in tty broke low latency feature

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

On 2014-02-19, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Hello,
>
> On Tue, Feb 18, 2014 at 05:12:13PM -0500, Peter Hurley wrote:
>> On 02/18/2014 04:38 AM, Stanislaw Gruszka wrote:
>>
>> >setserial has low_latency option which should minimize receive latency
>> >(scheduler delay). AFAICT it is used if someone talk to external device
>> >via RS-485/RS-232 and need to have quick requests and responses.

Exactly.

>>>
>>>But after 3.12 tty locking changes, calling flush_to_ldisc() from
>>>interrupt context is a bug (we got scheduling while atomic bug report
>>>here: https://bugzilla.redhat.com/show_bug.cgi?id=1065087 )
>>
>> Can you give me an idea of your device's average and minimum required
>> latency (please be specific)?

If by "device" you mean the UART being supported by the the driver in
question, then there is no answer.

Latency issues and requirements are a user-space application level
requirement that depend on the specific application's requirements and
those of the widget on the other end of the serial cable.

>> Also, how painful would it be if unsupported termios changes were rejected
>> if the port was in low_latency mode and/or if low_latency setting was
>> disallowed because of termios state?
>> 
>> It would be pointless to throttle low_latency, yes?

By "throttle" I assume you're talking about flow control?

_Usually_ applications that require low latency are exchanging short
messages (up to a few hundred bytes, but usually more like a few
dozen).  In those cases flow control is not generally needed.

Does it matter?

>> What would be an acceptable outcome of being unable to accept input?
>> Corrupted overrun? Dropped i/o? Queued for later? Please explain with
>> comparison to the outcome of missed minimum latency.
>
> I'm sorry, I can not answer your questions.
>
> For what I googled it looks like users wanted to get rid of 10ms jitter
> caused by scheduler.

Yes.  That was the use for the low_latency option. Historically, all
of my drivers had supported the low_latency options for customers that
found scheduling delays to be a problem.

However, low_latency has been broken in certain contexts for a long
time. As a result, drivers have to avoid using it either completely or
sometimes only where rx data is handled in certain contexts.

For some drivers the end result of that is that you can choose either
a low-latency I/O mechanism or low-latency TTY layer rx handling, but
you can't use both at the same time because the low-latency I/O
mechanism handles rx data in a context where low-latency TTY layer
stuff can't be used.

Now that HZ is often 1000 and tickless is commonly used, I don't think
the scheduling delay is nearly as much an issue as it used to be.  I
haven't gotten any complaints since it was largely rendered useless
several years ago.

Now all my drivers will silently override users if they set the
low_latency flag on a port in situations where it can't be used.

-- 
Grant Edwards               grant.b.edwards        Yow! OVER the underpass!
                                  at               UNDER the overpass!
                              gmail.com            Around the FUTURE and
                                                   BEYOND REPAIR!!