On Fri, Dec 09, 2016 at 03:44:56PM +0000, Rasmus Ahlberg wrote: > Hi, Hello! > We're running Linux with the RT patch on our single core ARM embedded > system, kernel version 3.14. Our application has several threads, of > which some are running in mode SCHED_RR, with different priorities. > > One of the higher prio SCHED_RR threads is dependent on data from the > TTY driver. In the driver, a workqueue is used to deliver the data > received, which is serviced by a kworker. The kworker runs in mode > SCHED_OTHER. If one of the lower priority SCHED_RR threads is running, > it will therefore block the kworker, and indirectly the higher prio > SCHED_RR thread. Is the workqueue usage that is problematic in the tty core? Or, is it in a specific driver? This is a more generic problem with most of the deferred work mechanisms that the kernel offers. Any work deferral system that doesn't map work units one-to-one with threads suffers the problem where the units cannot independently be prioritized amongst other system tasks. > Our tests show that the problem can be solved by setting mode SCHED_RR > for the kworker, which makes sense. However, this is not easily > implemented in the real system, as kworkers are created and destroyed > dynamically. Also, as the kworkers performs work for other drivers > also, this might not be optimal. > > What is the recommended way to solve this problem? Is there some > kernel option that solves this, or do we need to make our own > implementation? Everyone always asks "is there a kernel config option that magically fixes my problem?", and the answer is almost always "no" :). Without having more information about the case you are looking at, I think it will be difficult to prescribe a potential solution. If the workqueue is being used to defer work from interrupt context, then the use of request_threaded_irq() and pushing the work to thread context would be better. Hope that helps, Julia -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
