Messages in this thread | | | Date | Tue, 15 Jun 2010 18:42:30 +0200 | From | Tejun Heo <> | Subject | Re: [PATCH 27/30] workqueue: implement DEBUGFS/workqueue |
| |
Hello,
On 06/15/2010 03:54 PM, Frederic Weisbecker wrote: > 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.
Yeah, I agree that trace would be better way to do it. This patch was added because slow-work had similar facility and David was unhappy about losing easy way to monitor if cmwq replaces slow-work. I'll be happy to drop this one. David, what do you think?
Thanks.
-- tejun
| |