On Wed, 2 Dec 2015 17:56:51 -0500, Peter Hurley wrote: > Hi all, > > [other interested parties are welcome to contribute to the discussion] > > On 06/09/2015 02:05 PM, Steven Walter wrote: > > Use a dedicated kthread for handling ports marked as low_latency. Since > > this thread is RT_FIFO, it is not subject to the same types of > > starvation as the normal priority kworker threads. > > > > Some UART applications are very latency sensitive. In at least one case > > (motor controller card controlled over RS-232), a reply needs to be sent > > within about 1ms after receiving a byte. Without this patch, normal > > priority kworker threads can be delayed substantially by userspace > > real-time threads. This has been observed to cause latencies up to > > 100ms. With this patch, no occurences of communications failure were > > observed, meaning the 1ms latency is reliably achieved. > > For 4.4-rc*, I added an interface abstraction to the tty buffers > so that work can be restarted and cancelled with just a port parameter. > Please take a look. > > I'd like to revisit this solution to RT serial input handling, and > re-open the discussion with the following topic/suggestions/open-issues. > > First off, I've had a change-of-heart, and I think the kworker_thread > is a viable solution that we should take in mainline. > > I've copied Alan on this because he has way more experience than me > with exposing userspace interfaces. > > 1. I'm concerned about hooking this up to the low_latency knob. There's lots > of old userspace utils that flip the ASYNC_LOW_LATENCY bit just because. > And plenty of out-of-tree drivers do that too just because. Plus look at > the in-tree drivers that set low_latency just because. > > Multiple possibilities for exposing RT steering to userspace: > a. Existing solution - stick w/ low_latency > However, be aware that the current patch would be broken in this > regard because low_latency can be set via ioctl(TIOCSSERIAL) with a > running tty > b. Add an ASYNC_REALTIME bit to tty_port::flags > The benefit here is there is an existing interface that really is > never going away. The drawback is the it's only exposed via > TIOCGSERIAL/TIOCSSERIAL which could be an issue for other physical > transports that can't (or shouldn't) opt-in to the TIOCSSERIAL interface > c. We could expose the interface via sysfs knob(s). > d. (not a recommendation, just for completeness) Automagically on first > tty open based on the caller's scheduler. > e. some other solution not yet considered My very humble opinion would be to stick with existing interface (a). > 2. How or whether to expose the RT prio level? I personally see no use case for that ATM. (Since using kworker API gives us strong thread-TTY dev coupling people can simply modify the kthread prio from user space if they really need it.) > 3. I'd like to split this patch into two patches: > a. the core functionality tied to a port->realtime steering knob w/o a > userspace interface, and > b. the userspace interface for configuring > > 4. I think the kthread should be per-port. The input handling for the > N_TTY line discipline can block for a number of a reasons that I think > should be per-tty (which means per-port). Note that the core already > allows multiple concurrent flush_to_ldisc() operations on different > ttys. I'm for per-port. Do you envision sharing the kthread with drivers? It would be nice if drivers were allowed to schedule their work items on the same kthread since some of them (SPI, I2C ones) already have kthreads for async work. It's not a big deal but we could probably save a couple of context switches and halve the number of tty kthreads for those drivers. Thanks for reviving this work! -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
