> > 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)

This is starting to sound a lot like catch 22. We don't want it in the
kernel if nobody is using it. But nobody is using it because it is not in
the kernel.

Andrew Morton: そんなにトレースポイントって必要か? kprobe based tracerでいいじゃん
Steven Rostedt: キャッチ22的な状況だね。誰も使わないトレースポイントは入れたくないが