Re: RFC - Approaches to user-space probes

[Andi Kleen <ak@suse.de>]

On Tuesday 28 March 2006 11:42, Richard J Moore wrote:

> 1) ptrace is orientated to debugging a specific process tree and a
> nominated debug process. Having it operate on arbitrary process would
> require kernel extensions to achieve that but would also have a major
> impact on performance if each event were to result in a context switch to
> the debugger process.

You can attach it to any pid 

The problem is just finding new processes when they are created. And when
you trace all it will be quite inefficient.

> 
> 2) ptrace operates by privatizing memory via COW, but kprobes doesn't. The
> probes are fixed-up when a page is brought into memory by using an alias
> r/w virtual address. Using existing the ptrace mechanism across all, or
> most, processes could have a significant affect on swapfile and paging
> rate. And that has to be bad news when investigating performance and race
> conditions problems.

The problem with ptrace is also that it is quite heavyweight - you have
to take over all signals at least etc. Some lighter weight probing
mechanism for user space would be probably a good idea.

> If we want to make life easier for debugging the types of problems
> indicated above, then it's seems very reasonable to ask whether ptrace can
> be extended to use the (user) kprobes mechanism.

It's a mistery to me why people hate ioctl and like ptrace.

ptrace already is far too complex and ugly. Clean new calls would be probably
preferable. 

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/