Re: next steps

[Richard J Moore <richardj_moore at uk dot ibm dot com>]

"Frank Ch. Eigler" <fche@redhat.com> wrote on 21/09/2005 21:56:10:

> Hi -
>
> > Frank, under improving kprobes I would add:
>
> Thanks for the suggestions.
>
> > 1) dprobes or a scalable mechanism for performance tracing [...]
>
> Could you elaborate on what exactly "scalable ... tracing" refers to,
> and how you believe we're short of this?
>

Frank, this is a reference to earlier discussion relating to the
inefficiency of the interrupt mechanism.
On the one hand the int3 mechanism allows use to probes in almost all
contexts under almost any condition. But it is relatively slow.
For debugging purposes it's usually good enough.

However, for performance measurements, once need a mechanism that perturbs
the system timing as little as possible - even if some events are lost.
I believe djprobes attempts to fulfil this need, but if my understanding is
correct there are some unfortunate restrictions to its deployment. So, I'm
lodging a request that this issue be further discussed at the very least to
determine whether there is a real need to address it, which I believe
there. For example using the current mechanism to trace interrupts from a
Gb ethernet NIC is not going to work particularly well.

> > 2) watchpoint probes if these aren't already there. [...]
>
> This is already tracked by bug #1324.  A prerequisite is a debug
> register management API in the kernel.
>
> > 3) add back the ability to place probes in a code location before
> > the module is loaded. [...]  We used to have this capability for
> > kernel modules. It relied on patches in insmod. Clearly this is
> > useful especially when wanting to capture initialization module
> > problems.
>
> Sounds useful, especially if it can be accomplished without much or
> any patching of generic kernel or kernel-utils code.  Might the
> register_module_notifier() hook be sufficient for this?  It's worth
> creating a bugzilla item for this.  Bug #1145 is a prerequisite.
>
> > 4) Finally I'd request that we re-instate the SysRq function to
> > disable all probes instantly. [...]
>
> Please create a bugzilla item.  __sysrq_put_key_op is probably
> suitable, as long as a handler doesn't try to do much anything fancy.
> Is it safe to instantly remove all kprobes at an arbitrary moment?
>
> > Apart from 1) all of these are simple modification for which the
> > code has all ready been written.
>
> These are good, though was intending to list the *larger* missing
> chunks: leaps of usefulness that would excite ordinary developers, not
> just kernel hackers.
>
>
> - FChE