diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2014-12-11 18:48:45 -0800 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2014-12-11 18:48:45 -0800 |
commit | 0a27044c83fe8f52fd8fd1964d17fa7538ea0771 (patch) | |
tree | cd6df6ca2154c03249a6f64b62bca09fed1de686 /include/linux/scx200_gpio.h | |
parent | eedb3d3304b59c64c811522f4ebaaf83124deeac (diff) | |
parent | 008847f66c38712f2819cd956969519006ebc11d (diff) | |
download | talos-op-linux-0a27044c83fe8f52fd8fd1964d17fa7538ea0771.tar.gz talos-op-linux-0a27044c83fe8f52fd8fd1964d17fa7538ea0771.zip |
Merge branch 'for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq
Pull workqueue update from Tejun Heo:
"Work items which may be involved in memory reclaim path may be
executed by the rescuer under memory pressure. When a rescuer gets
activated, it processes whatever are on the pending list and then goes
back to sleep until the manager kicks it again which involves 100ms
delay.
This is problematic for self-requeueing work items or the ones running
on ordered workqueues as there always is only one work item on the
pending list when the rescuer kicks in. The execution of that work
item produces more to execute but the rescuer won't see them until
after the said 100ms has passed, so such workqueues would only execute
one work item every 100ms under prolonged memory pressure, which BTW
may be being prolonged due to the slow execution.
Neil wrote up a patch which fixes this issue by keeping the rescuer
working as long as the target workqueue is busy but doesn't have
enough workers"
* 'for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: allow rescuer thread to do more work.
workqueue: invert the order between pool->lock and wq_mayday_lock
workqueue: cosmetic update in rescuer_thread()
Diffstat (limited to 'include/linux/scx200_gpio.h')
0 files changed, 0 insertions, 0 deletions