Re: DTrace-like analysis possible with future Linux kernels?

Alan Cox
2004-08-22T19:48:32Z

On Sul, 2004-08-22 at 19:27, Tomasz Kłoczko wrote:
> Using yor thing path: KProbe/Dtrace is for development and yes it must
> depend on DEBUG_KERNEL.
> ptrace() is also for tracing and ver offen used by developers but it is
> enabled by default and it is not only for developers. So .. ptrace() must
> also depend on DEBUG_KERNEL.

ptrace is for debugging user space, as for example is oprofile. kprobes
is for debugging including kernel internal goings on

> compilation stage). In Solaris kernel exist few thousands avalaible probes
> and IIRC only very small subset is "near zero effect" (uses nop
> instructions).

Sounds like a kprobes clone 8).

> > OProfile doesn't require this.
>
> As same as KProbe/DTrace. Can you use OProfile for something other tnan
> profiling ? Probably yes and this answer opens: probably it will be good
> prepare some common code for KProbe and Oprofile.

Oprofile lets you work on stuff like cache affinity, tuning array walks
and prefetches. Short of running the app under cachegrind its one of the
most detailed ways of getting all the profile register data from the x86
processors.

> So it will be good stop disscuss about "yes or no ?" and start about
> "how and when in Linux ?" ..

When you send patches ?

> > We have crash dumps - at least all the enterprise vendors do. Linus
> > doesn't seem to like that stuff so much.
> It need some more advanced additional tools for analize and report data
> from CD.

Standard debugging tools. The system dumps across the network to a
server and then you can analyse it offline

> OProfile it will be good integrate ASAP also things like KProbes and CD.
> It is not only extenging entropy kernel tree. IMO KProbe can bring some
> functionalities wich can be common also for OProfile and probably in
> future IMO OProfile can be droped.

You clearly haven't understood what Oprofile does. Its a parallel
technology that is more in common with say Intel's vtune.