On Fri, 2014-06-27 at 18:18 -0700, Austin Schuh wrote: > It would be more context switches, but I wonder if we could kick the > workqueue logic completely out of the scheduler into a thread. Have > the scheduler increment/decrement an atomic pool counter, and wake up > the monitoring thread to spawn new threads when needed? That would > get rid of the recursive pool lock problem, and should reduce > scheduler latency if we would need to spawn a new thread. I was wondering the same thing, and not only for workqueue, but also the plug pulling. It's kind of a wart to have that stuff sitting in the hear of the scheduler in the first place, would be nice if it just went away. When a task can't help itself, you _could_ wake a proxy do that for you. Trouble is, I can imagine that being a heck of a lot of context switches with some loads.. and who's gonna help the helper when he blocks while trying to help? -Mike -- 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
