[lkml]   [2012]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCHSET] workqueue: reimplement high priority using a separate worker pool
Currently, WQ_HIGHPRI workqueues share the same worker pool as the
normal priority ones. The only difference is that work items from
highpri wq are queued at the head instead of tail of the worklist. On
pathological cases, this simplistics highpri implementation doesn't
seem to be sufficient.

For example, block layer request_queue delayed processing uses high
priority delayed_work to restart request processing after a short
delay. Unfortunately, it doesn't seem to take too much to push the
latency between the delay timer expiring and the work item execution
to few second range leading to unintended long idling of the
underlying device. There seem to be real-world cases where this
latency shows up[1].

A simplistic test case is measuring queue-to-execution latencies with
a lot of threads saturating CPU cycles. Measuring over 300sec period
with 3000 0-nice threads performing 1ms sleeps continuously and a
highpri work item being repeatedly queued with 1 jiffy interval on a
single CPU machine, the top latency was 1624ms and the average of top
20 was 1268ms with stdev 927ms.

This patchset reimplements high priority workqueues so that it uses a
separate worklist and worker pool. Now each global_cwq contains two
worker_pools - one for normal priority work items and the other for
high priority. Each has its own worklist and worker pool and the
highpri worker pool is populated with worker threads w/ -20 nice

This reimplementation brings down the top latency to 16ms with top 20
average of 3.8ms w/ stdev 5.6ms. The original block layer bug hasn't
been verfieid to be fixed yet (Josh?).

The addition of separate worker pools doesn't add much to the
complexity but does add more threads per cpu. Highpri worker pool is
expected to remain small, but the effect is noticeable especially in
idle states.

I'm cc'ing all WQ_HIGHPRI users - block, bio-integrity, crypto, gfs2,
xfs and bluetooth. Now you guys get proper high priority scheduling
for highpri work items; however, with more power comes more

Especially, the ones with both WQ_HIGHPRI and WQ_CPU_INTENSIVE -
bio-integrity and crypto - may end up dominating CPU usage. I think
it should be mostly okay for bio-integrity considering it sits right
in the block request completion path. I don't know enough about
tegra-aes tho. aes_workqueue_handler() seems to mostly interact with
the hardware crypto. Is it actually cpu cycle intensive?

This patchset contains the following six patches.


0001 makes unbound wq not use WQ_HIGHPRI as its meaning will be
changing and won't suit the purpose unbound wq is using it for.

0002-0005 gradually pulls out worker_pool from global_cwq and update
code paths to be able to deal with multiple worker_pools per

0006 replaces the head-queueing WQ_HIGHPRI implementation with the one
with separate worker_pool using the multiple worker_pool mechanism
previously implemented.

The patchset is available in the following git branch.

git:// review-wq-highpri

diffstat follows.

Documentation/workqueue.txt | 103 ++----
include/trace/events/workqueue.h | 2
kernel/workqueue.c | 624 +++++++++++++++++++++------------------
3 files changed, 385 insertions(+), 344 deletions(-)




 \ /
  Last update: 2012-07-09 21:41    [W:0.119 / U:0.364 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site