Thread (26 messages) 26 messages, 5 authors, 2014-07-06

Re: Filesystem lockup with CONFIG_PREEMPT_RT

From: Mike Galbraith <hidden>
Date: 2014-06-28 03:32:18
Also in: lkml

Possibly related (same subject, not in this thread)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help