Re: locking changes in tty broke low latency feature

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

> Ok, so this is still only about "best effort", and really bad
> worst case behavior (that the tty core has no control over) is ok.
> 
> Going to great lengths to trim one wakeup when nouveau disables interrupts
> for 2ms seemed like a waste of time.

If it used to work and it doesn't now it's a regression. It's also a
nasty one if you've removed the facility for it.

> This change makes flush_to_ldisc() itself safely callable from
> interrupt context, and:
> 1. doesn't lose data (ie., buffers if the ldisc is filling up)
> 2. automatically picks the optimum handling whether the input worker
>     is running or not
> 3. doesn't require more locks to exclude flushing or the input worker

Yep

> Putting aside for a moment the issue of termios safety inside
> the throttle and unthrottle driver methods, the exclusion locks here could
> be spinlocks if the drivers can be audited/fixed to not sleep here.

That was basically insoluble when the lock first went in. We tried with a
spinlock but a lot of USB widgets need to go and chatter with the device
when you do flow control. Flow control is fundamentally ordered but
asynchronous however so if the right fix was to make the USB dongles
queue the work then no harm is done (and the queued flow control
assertion would worst case be no different to a non queued one from a
queued flush_to_ldisc)

> Then that just leaves the termios lock, which is a non-trivial problem, and
> I'm not convinced RCU will magically fix it.

If you pass a snapshot of the termios state down then I think it does,
but it's still not remotely trivial.

First question though comes before all of this - and that is do we need
low_latency at all any more or is the current scheduling logic now good
enough to do the job anyway.

Alan