Re: [PATCH 0/2 v2] Syscalls tracing

Ingo Molnar
2009-03-23T19:40:57Z

* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> And actually I don't think two copy_from_user will really change a
> lot the tracing throughput.

Correct. It's already in the CPU cache so it is a performance
non-issue and essentially for free. Copy avoidance is only an issue
when touchig cache-cold data.

( Yes, a few cycles could be shaven off but the beauty of
all-encompassing non-source-code-invasive syscall tracing covering
hundreds of syscalls straight away trumps those concerns. )

> The idea would be now to join the syscalls metadata with such
> quick handlers. We will have to think about how to join these in a
> proper way.

We could allow per syscall tracepoints via the attribute table. The
call signature could be a standard:

long sys_call(unsinged long arg1, unsigned long arg2,
unsigned long arg3, unsigned long arg4,
unsigned long arg5, unsigned long arg6);

This would allow interested plugins/tools to install a system call
specific callback. (we might allow two tracepoints - one before and
one after the syscall)

The registration API could be driven by the name or by the syscall
index - NR_sys_open or so.

Ingo