Re: [PATCH 0/4] workqueue_tracepoint: Add worklet tracepoints for worklet lifecycle tracing

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 24 Apr 2009 22:00:20 -0400 (EDT) Steven Rostedt <rostedt@goodmis.org> wrote:

> 
> I agree that we need to be frugal with the addition of trace points. But 
> I don't think the bugs that can be solved with this is always reproducible 
> by the developer.
> 
> If you have a distribution kernel that is running at a customers location, 
> you may not have the privilege of shutting down that kernel, patching the 
> code, recompiling and booting up this temporary kernel. It would be nice 
> to have strategic locations in the kernel where we can easily enable a 
> trace point and monitor what is going on.
> 
> If the customer calls and tells you there's some strange performance 
> issues when running such and such a load, it would be nice to look at 
> things like workqueues to analyze the situation.

Would it?  What's the probability that anyone anywhere will *really*
solve an on-site problem using workqueue tracepoints?  Just one person?

I think the probability is quite small, and I doubt if it's high enough
to add permanent code to the kernel.

Plus: what we _really_ should be looking at is

p(someone uses this for something) -
	p(they could have used a kprobes-based tracer)

no?

> Point being, the events are not for me on the box that runs my machines.
> Hell, I had Logdev for 10 years doing that for me. But now to have 
> something that is running at a customers site with extremely low overhead 
> that we can enable when problems arise. That is what makes this worth 
> while.
> 
> Note, when I was contracting, I even had logdev prints inside the 
> production (custom) kernel that I could turn on and off. This was exactly 
> for this purpose. To monitor what is happening inside the kernel when in 
> the field.

We seem to be thrashing around grasping at straws which might justify
the merging of these tracing patches.  It ain't supposed to be that way.