On Sun, 2016-02-28 at 18:01 +0100, Francois Romieu wrote: > Mike Galbraith <umgwanakikbuti@xxxxxxxxx> : > [...] > > Hrm, relatively new + tasklet woes rings a bell. Ah, that.. > > > > > > What's worse is that at the point where this code was written it was > > already well known that tasklets are a steaming pile of crap and > > should die. > > > > > > Source thereof https://lwn.net/Articles/588457/ > > tasklets are ingrained in the dmaengine API (see Documentation/dmaengine/client.txt > and drivers/dma/virt-dma.h::vchan_cookie_complete). > > Moving everything to irq context or handling his own sub-{jiffy/ms} timer > while losing async dma doesn't exactly smell like roses either. :o( https://lwn.net/Articles/239633/ If I'm listening properly, the root cause is that there is a timing constraint involved, which is being exposed because one softirq raises another (ew). Processing timeout happens, freshly raised tasklet wanders off to SCHED_NORMAL kthread context where its constraint dies. Given the dma stuff apparently works fine in -rt (or did, see below), timing constraints can't be super tight, so perhaps we could grow realtime workqueue support for the truly deserving. The tricky bit would be being keeping everybody and his brother from abusing it. WRT -rt: if dma tasklets really do have hard (ish) constraints, -rt recently "broke" in the same way.. of all softirqs which are deferred to kthread context, due to a recent change, only timer/hrtimer are executed at realtime priority by default. -Mike -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
