This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new static user probe types


On 07/15/2009 01:47 PM, Stan Cox wrote:
> Josh Stone wrote:
>> On 07/15/2009 09:19 AM, Stan Cox wrote:
>>   
>>
>> task_tid(task_current()) == tid(), and the latter should be faster.  But
>> anyway, it's not clear to me what this is guarding against.
>>
>>   
> An application sets up a kprobe probe by hijacking a syscall, currently 
> SYS_getegid, and passing the tid.  On the stap side the .mark probe gets 
> converted to kernel.function("sys_getegid") so the guard wants to make 
> certain we didn't get here via another task doing a SYS_getegid syscall.

Ok, so really any magic value would work, right?  Why not use the
STAP_GUARD constant and avoid the extra gettid syscalls in the app?
Then the guard doesn't need to be part of the other arguments either.

Also, I see this in sdt.h:
> # if defined EXPERIMENTAL_KPROBE_SDT
> # define STAP_SYSCALL __NR_getegid
> # define STAP_GUARD 0x32425250
> # define GETTID 0
> # elif defined EXPERIMENTAL_UTRACE_SDT
> # define STAP_SYSCALL 0xbead
> # define STAP_GUARD 0x33425250
> # define GETTID syscall(SYS_gettid)
> # endif

It would appear that you're always passing 0 in place of a tid in the
kprobe version.  Wouldn't that mean the kprobe version is always
skipping the probe body?

And then the guard code you gave for utrace is not using the tid check,
even though it is generating a real GETTID.  It seems that the gettid()
penalties are reversed here.

But again, perhaps we don't need the tid at all...

>> Beware that the 1953719668 constant is little-endian specific.
>>
>> I'm also nervous about saving _stp_probe_name_XXX -- murphy's law may
>> eventually produce a mark in one app that happens to have the same
>> pointer address as a different mark in a different app.
>>   
> There will be a series of probes for the hijacked syscall, one per 
> marker type.  So if this is postgres there would be one for 
> transaction__start, lwlock__acquire, etc.  So it is necessary to check 
> that the probe for transaction__start actually arrived here from a 
> transaction__start.  The probe name is passed in so the easy way to do 
> this is to compare the passed in probe name to the .mark("marker_name") 
> and check that they match.  However it would be nice to "optimize" this 
> so the string comparison is avoided if there is a lower cost 
> alternative.  That is what my experiment was trying to achieve. Any 
> clever suggestions on how to do that?

Correctness always trumps optimization (unfortunately).

It looks like a large part of the oprofile overhead is in strlcpy, which
is probably script code preparing to do the strcmp.  You might be able
to reduce the overhead by doing the checks in native C rather than
synthesizing script code.  You could write C in emit_probe_local_init
instead, and then you'd even be able to skip probes before locks are
attempted.

Using a hash or UUID instead of strings might also help, but I don't
know how to generate that in macros...

Josh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]