]> git.baikalelectronics.ru Git - kernel.git/commit
Merge branch 'for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq
authorLinus Torvalds <torvalds@linux-foundation.org>
Fri, 12 Dec 2014 02:48:45 +0000 (18:48 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 12 Dec 2014 02:48:45 +0000 (18:48 -0800)
commitd4e5c8f96794f822e5abfaf908b76a2319bb27d5
treecd6df6ca2154c03249a6f64b62bca09fed1de686
parent28a2f0af335f585a05b83debe85347799bf77f75
parent279006bfd9df97bae3514bf1b4f4fb4a45e67c90
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()