On Thu, 11 Jun 2015 08:15:52 -0400, Peter Hurley wrote: > On 06/11/2015 05:38 AM, Jakub Kiciński wrote: > > On Wed, 10 Jun 2015 07:32:52 -0400, Peter Hurley wrote: > >> 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. > >> > >> This is not a problem unique to the tty subsystem; many subsystems use > >> kworkers to handle i/o after the initial ISR. > >> > >> Without careful design, high-prio userspace RT threads can effectively starve > >> themselves of i/o. > >> > >> In any event, solutions to this problem belong either in the core workqueue > >> (for example, an i/o-specific unbounded workqueue) or in the CONFIG_PREEMPT_RT > >> patch. > > > > But kthread_worker *is* the workqueue subsystem's answer to users who > > require low-latency processing. > > Not really; you even note below the lack of RT support in wq. By "workqueue subsystem's answer" I meant Tejun's answer ;) It's not part of workqueue subsys though hence the remark that wq lacks RT below. Here's rationale for kthread_worker explicitly mentioning RT: http://thread.gmane.org/gmane.linux.kernel/998652/focus=1000764 > > Lack of RT functionality in workqueue subsystem and prevalence of wq use makes > > them a huge pain on embedded/rt systems. I would like to see more > > generic solution to this problem as well but I can't think of one :/ > > Direct support from workqueue is the generic solution, insofar as there is a > generic solution. Ultimately, RT priority inversion is a upward spiral to 99. > > tty uses the system_unbound_wq; as long as the substitute wq has similar > guarantees (guaranteed forward progress and unbounded worker running times) > using a different wq for any given tty_port would be ok. > > I'd like to see whatever solution go through CONFIG_PREEMPT_RT patch first though, > since there is no linux-rt list/tree, especially for proposals that are pushing > down into the device subsystems. Makes sense, agreed. -- 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
