|| ||Tejun Heo <firstname.lastname@example.org> |
|| ||email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com |
|| ||[RFC PATCHSET] workqueue: implement concurrency managed workqueue |
|| ||Thu, 1 Oct 2009 17:08:59 +0900|
|| ||Article, Thread
This rather large patchset implements concurrency managed workqueue.
It's not complete yet. Singlethread workqueue handling needs more
work and workqueue users need to be audited and simplified and async
and slow-work should be reimplemented in terms of workqueue. Although
this patchset currently adds ~2000 lines of code, I'm fairly
optimistic that after the whole conversion is done, it would be a net
decrease in lines of code.
This patchset reimplements workqueue such that it auto-regulates
concurrency and thus relieves its users from the managing duty. It
works by managing single shared pool of per-cpu workers and hooking
into the scheduler to get notifications about workers going to sleep
and waking up. Using the mechanism, workqueue implementation keeps
track of the current level of concurrency and schedules only the
necessary number of workers to keep the cpu occupied.
Concurrency managed workqueue has the following benefits.
* Workqueue users no longer have to worry about managing concurrency
and, in most cases, deadlocks. The workqueue will manage it
automatically and unless the deadlock chain involves many (currently
127) works, it won't happen.
* There's one single shared pool of workers per cpu and one rescuer
for each workqueue which requires it, so there are far fewer number
* More efficient. Although it adds considerable amount of code, the
code added to hot path isn't big and works will be executed on the
local cpu and in batch as much as possible using minimal number of
kthreads leading to fewer task switches and lower cache
footprint. <NEED SOME BACKING NUMBERS>
* As concurrency is no longer a problem, most types of asynchronous
jobs can be done using generic workqueue and other async mechanisms,
including slow-work, async and adhoc subsystem custom ones, can be
removed. ie. It can serve as the unified async thread pool
Please read the patch description of the last patch for more details.
This patchset contains the following 19 patches and most of these are
not signed off yet.
0001 makes freezer less anxious. It's a mostly unrelated change I did
while looking at the code.
0002-0004 implements scheduler callback for workqueue.
0005 implements kthread_data() which will be used to get back at the
workqueue worker data structure from scheduler callbacks.
0006-0007 kill exotic usages of workqueue.
0008-0010 does misc preparations in workqueue code.
0011-0014 strip out some features from workqueue to prepare for new
implementation. Please note that 0014 is incorrect and I'm currently
working on proper solution.
0015-0018 reimplement flushing and freezing in a way which is friendly
to multiple workers per cpu.
0019 implements concurrency managed workqueue.
Please note that none of the workqueue users has been updated yet. It
will work fine but most workqueues which don't need rescuer would
I'm attaching test-wq source and Makefile which I used to verify each
aspect of the new workqueue. It's pretty easy to write new test
scenarios using the module so if you're interested in how this
actually work, it is quite useful.
This patchset is on top of the current linus#master
(817b33d38f81c8736d39283c35c886ae4668f1af) and available in the
following git tree.
and contains the following changes.
drivers/acpi/osl.c | 41
include/linux/kthread.h | 1
include/linux/sched.h | 9
include/linux/stop_machine.h | 6
include/linux/workqueue.h | 63 -
init/main.c | 2
kernel/kthread.c | 15
kernel/power/process.c | 34
kernel/sched.c | 105 +
kernel/sched_fair.c | 62 -
kernel/sched_idletask.c | 1
kernel/sched_rt.c | 1
kernel/sched_workqueue.c | 130 ++
kernel/sched_workqueue.h | 17
kernel/stop_machine.c | 151 ++
kernel/trace/Kconfig | 4
kernel/workqueue.c | 2268 ++++++++++++++++++++++++++++++++++++-------
17 files changed, 2417 insertions(+), 493 deletions(-)
So, what do you guys think?
PS. I'm still working on it and will probably write up about overall
design under Documentation.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/