On 2014-02-21, Peter Hurley <pe...@hurleysoftware.com> wrote: > I think the consensus is to leave the low_latency facility in, but > remove it's connection to the tty buffers. > > If the known-to-be-already-in-non-interrupt-context drivers want, > I can add a different function for executing flush_to_ldisc() > directly. But I don't want to do that without a use-case and test > subject.
Three of the drivers I maintain have modes where they handle all rx data in non-interrupt contexts, but I'm not convinced (or even suspicious) that there would be any noticeable benefit from such a function. If, at some point in the future, it becomes apparent that there is "too much latency" in certain cases then perhaps it can be looked at again -- but I think doing it now is premature optimization. That said, all things being equal, it would be nice to avoid anything that would make such an addition impossible in the future. >> 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. > > Right. > > Based on my recent test, I think low_latency doesn't need to be a > knob for the tty core. I Agree: there doesn't seem to be any evidence that it's needed by the tty/ldisc layer. > Drivers can continue to use it to mess with their rx fifo settings > and such like. Excellent. One of my serial_core drivers still has (in it's default configuration) 10ms of latency that I can choose to eliminate on a per-port bases (at the cost of extra CPU cycles) when the low_latency flag is set. > I plan on sending Greg a patch to do just that, probably this weekend. Cool. Thanks much for your attention to this. -- Grant -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
