diff options
author | Ingo Molnar <mingo@elte.hu> | 2011-05-10 17:05:24 +0200 |
---|---|---|
committer | Ingo Molnar <mingo@elte.hu> | 2011-05-10 17:05:45 +0200 |
commit | 932fed4e2e42c3d730c01bb63b1c4f812c533d5b (patch) | |
tree | 11b1afac3a40d253cdb905c42901edfaae5e196e /Documentation/workqueue.txt | |
parent | 57d524154ffe99d27fb55e0e30ddbad9f4c35806 (diff) | |
parent | 693d92a1bbc9e42681c42ed190bd42b636ca876f (diff) | |
download | linux-932fed4e2e42c3d730c01bb63b1c4f812c533d5b.tar.bz2 |
Merge commit 'v2.6.39-rc7' into perf/core
Merge reason: pull in the latest fixes.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'Documentation/workqueue.txt')
-rw-r--r-- | Documentation/workqueue.txt | 40 |
1 files changed, 40 insertions, 0 deletions
diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt index 01c513fac40e..a0b577de918f 100644 --- a/Documentation/workqueue.txt +++ b/Documentation/workqueue.txt @@ -12,6 +12,7 @@ CONTENTS 4. Application Programming Interface (API) 5. Example Execution Scenarios 6. Guidelines +7. Debugging 1. Introduction @@ -379,3 +380,42 @@ If q1 has WQ_CPU_INTENSIVE set, * Unless work items are expected to consume a huge amount of CPU cycles, using a bound wq is usually beneficial due to the increased level of locality in wq operations and work item execution. + + +7. Debugging + +Because the work functions are executed by generic worker threads +there are a few tricks needed to shed some light on misbehaving +workqueue users. + +Worker threads show up in the process list as: + +root 5671 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/0:1] +root 5672 0.0 0.0 0 0 ? S 12:07 0:00 [kworker/1:2] +root 5673 0.0 0.0 0 0 ? S 12:12 0:00 [kworker/0:0] +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 + 2. A single work item that consumes lots of cpu cycles + +The first one can be tracked using tracing: + + $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event + $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt + (wait a few secs) + ^C + +If something is busy looping on work queueing, it would be dominating +the output and the offender can be determined with the work item +function. + +For the second type of problems it should be possible to just check +the stack trace of the offending worker thread. + + $ cat /proc/THE_OFFENDING_KWORKER/stack + +The work item's function should be trivially visible in the stack +trace. |