Hi Jakub, On 12/03/2015 04:52 AM, Jakub Kiciński wrote: > 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. I'm not understanding why uart drivers are using RT kthreads. > 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
