Re: [PATCH 27/30] workqueue: implement DEBUGFS/workqueue

[Frederic Weisbecker <fweisbec@gmail.com>]

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.