Re: patches to actually use markers?

[David Smith <dsmith at redhat dot com>]

Mathieu Desnoyers wrote:
> * David Smith (dsmith@redhat.com) wrote:
>>>> Mathieu
>> I've been looking at your system call tracing patches.  (I've tried
>> running lttv itself without much luck, but it doesn't really matter for
>> the sake of this discussion.)
>>
>> I like the way you use the existing system call tracing points.  So
>> we're on the same page, here are the markers I'm seeing in
>> arch/x86/kernel/ptrace32.c after applying
>> patch-2.6.24-rc2-lttng-0.10-pre23.tar.bz2:
>>
>>   trace_mark(kernel_arch_syscall_entry, "syscall_id %d ip #p%ld",
>> 			(int)regs->orig_eax, instruction_pointer(regs));
>>
>>   trace_mark(kernel_arch_syscall_exit, MARK_NOARGS);
>>
>> For systemtap use, we'd like to have more information than that.  On
>> syscall entry, we'd like be able to get the arguments,  On syscall exit,
>> we'd like the to be able to get the return value.  In fact, the easiest
>> thing would be to supply the same information that audit_syscall_entry()
>> and audit_syscall_exit() need.
>>
>> Since I'll bet you've already considered this, I'd like to know why you
>> decided to go a different way.
>>
> Well, the approach taken was to instrument each important system call in
> the syscall specific function to be able to actually know what type of
> information to record. For instance, if ebx points to a string, the
> pointer is not very useful, but the string is.

That is (somewhat) true in the case of strings.

But, similar problems exist with syscalls that take structure pointers:
sys_[gs]ettimeofday, sys_adjtimex, sys_times, sys_nanosleep,
sys_[gs]etitimer, sys_timer_create, sys_timer_[gs]ettime,
sys_clock_gettime, sys_clock_getres, sys_clock_nanosleep,
sys_sched_setscheduler, sys_sched_[gs]etparam, sys_wait4, sys_waitid,
sys_rt_sigtimedwait, sys_stat, sys_statfs[64], sys_fstatfs[64],
sys_lstat, sys_fstat, and so on (I got tired of looking through syscalls.h).

For those syscalls only a pointer can be passed so the marker handler
will have to know how to handle that pointer.  That marker handler will
need to know that that value is a pointer to a particular structure type
and then know how to access it accordingly.

The same could be done for strings.  Is it a little more work?  Yes.  Is
it fairly easy?  Yes.

Let me ask the question another way.  Is there a (measurable)
performance hit if the extra arguments to the syscall entry marker are
added?  If not, even if lttng doesn't plan to use them, why not add
them?  Certainly systemtap (and perhaps other users) could use them.

> You have a good point for the syscall exit instrumentation : adding the
> return value is trivial and would be very useful.

I'm glad we agree that adding the return value is useful and trivial.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)