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

From: Tomasz Kłoczko
Date: Mon Aug 23 2004 - 12:42:07 EST


On Sun, 22 Aug 2004, Alan Cox wrote:

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

Yes. It *is* for debuging/tracing in kernel space but like DTrace is *also* in user space.

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

Look on some time stamps both projects.
Seems KProbes is clone DTrace ..

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.

The same is KProbes but you can combined with small programs associated with called probes. Again: DTrace/KProbes is much more than traditional
profiling/tracing/measuring tools.

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

When you send patches ?

KProbes patches was annouced on lkml few times.

kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@xxxxxxxxxxxxxxxxxx*