lkml.org 
[lkml]   [2010]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 27/30] workqueue: implement DEBUGFS/workqueue
On Mon, Jun 14, 2010 at 11:37:44PM +0200, Tejun Heo wrote:
> Implement DEBUGFS/workqueue which lists all workers and works for
> debugging. Workqueues can also have ->show_work() callback which
> describes a pending or running work in custom way. If ->show_work()
> is missing or returns %false, wchan is printed.
>
> # cat /sys/kernel/debug/workqueue
>
> CPU ID PID WORK ADDR WORKQUEUE TIME DESC
> ==== ==== ===== ================ ============ ===== ============================
> 0 0 15 ffffffffa0004708 test-wq-04 1 s test_work_fn+0x469/0x690 [test_wq]
> 0 2 4146 <IDLE> 0us
> 0 1 21 <IDLE> 4 s
> 0 DELA ffffffffa00047b0 test-wq-04 1 s test work 2
> 1 1 418 <IDLE> 780ms
> 1 0 16 <IDLE> 40 s
> 1 2 443 <IDLE> 40 s
>
> Workqueue debugfs support is suggested by David Howells and
> implementation mostly mimics that of slow-work.
>
> * Anton Blanchard spotted that ITER_* constants are overflowing w/
> high cpu configuration. This was caused by using
> powerup_power_of_two() where order_base_2() should have been used.
> Fixed.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Anton Blanchard <anton@samba.org>
> ---
> include/linux/workqueue.h | 12 ++
> kernel/workqueue.c | 369 ++++++++++++++++++++++++++++++++++++++++++++-
> lib/Kconfig.debug | 7 +
> 3 files changed, 384 insertions(+), 4 deletions(-)



I don't like this. This adds 300 lines of ad hoc in-kernel instrumentation code while
we now have a nice kernel tracing API (trace events) coupled with easy userspace
tools to post-process that (perf trace scripting). And this is going to provide
a much more powerful view of your new workqueue implementation runtime behaviour.

We already have kernel/trace/trace_workqueue.c that has been obsolated for these
very reasons and we are even going to remove it soon, probably for .36

Please work with us for that, if everybody makes his own corner instrumentation, we
are not going to make any progress in having a powerful and unified tracing/profiling.

The first step is to pinpoint the important places that need tracepoints,
and then just write a perf trace script to use the provided informations by these
tracepoints.

I can help about that if needed.



\
 
 \ /
  Last update: 2010-06-15 15:57    [from the cache]
©2003-2011 Jasper Spaans