summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2015-06-26 20:12:21 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2015-06-26 20:12:21 -0700
commite0dd880a545c36bd56489a97bb1d337cb873a9d5 (patch)
tree2d72d3473cb31e787777ac16ea1d18f4218d8d2d /Documentation
parentbbe179f88d39274630823a0dc07d2714fd19a103 (diff)
parent402dd89d6cdbeeaab42b810542b487017725c628 (diff)
Merge branch 'for-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq
Pull workqueue updates from Tejun Heo: "Most of the changes are around implementing and fixing fallouts from sysfs and internal interface to limit the CPUs available to all unbound workqueues to help isolating CPUs. It needs more work as ordered workqueues can roam unrestricted but still is a significant improvement" * 'for-4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: fix typos in comments workqueue: move flush_scheduled_work() to workqueue.h workqueue: remove the lock from wq_sysfs_prep_attrs() workqueue: remove the declaration of copy_workqueue_attrs() workqueue: ensure attrs changes are properly synchronized workqueue: separate out and refactor the locking of applying attrs workqueue: simplify wq_update_unbound_numa() workqueue: wq_pool_mutex protects the attrs-installation workqueue: fix a typo workqueue: function name in the comment differs from the real function name workqueue: fix trivial typo in Documentation/workqueue.txt workqueue: Allow modifying low level unbound workqueue cpumask workqueue: Create low-level unbound workqueues cpumask workqueue: split apply_workqueue_attrs() into 3 stages
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/workqueue.txt2
1 files changed, 1 insertions, 1 deletions
diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt
index f81a65b54c29..5e0e05c5183e 100644
--- a/Documentation/workqueue.txt
+++ b/Documentation/workqueue.txt
@@ -365,7 +365,7 @@ root 5674 0.0 0.0 0 0 ? S 12:13 0:00 [kworker/1:0]
If kworkers are going crazy (using too much cpu), there are two types
of possible problems:
- 1. Something beeing scheduled in rapid succession
+ 1. Something being scheduled in rapid succession
2. A single work item that consumes lots of cpu cycles
The first one can be tracked using tracing: