stap -x option

stap -x option

[Sanket Somnath Hase]

Hi folks,

a ) I was curious to know if we can provide more than one target to stap. Say I want to run the same script for more than one processes .

b) Is there any benefit in running single script ( effectively single kernel module ) for all the processes under consideration  against running same script for each process individually ( and effectively  having many kernel modules which look for same set of events but for different targets ).

Looking forward to hear from you ,

Thanks ,
Sanket

Re: stap -x option

[Martin Hunt]

On Fri, 2007-07-27 at 13:59 -0400, Sanket Somnath Hase wrote:
> Hi folks,
> 
> a ) I was curious to know if we can provide more than one target to stap. 
> Say I want to run the same script for more than one processes .

-x is probably not needed now that we handle command line args. However
it is a nice complement to -c.

Anyway, what you want is easy to do use command line args. For example,

probe begin {
        printf("tracing pids %d and %d\n", $1, $2)
}

probe syscall.open {
        p = pid()
        if (p == $1 || p == $2)
                printf("%d: open (%s)\n", p, argstr)
}
Save the above as trace.stp and then
> stap trace.stp 123 456

> 
> b) Is there any benefit in running single script ( effectively single kernel module ) 
> for all the processes under consideration  against running same script for each process 
> individually ( and effectively  having many kernel modules which look for same set of 
> events but for different targets ).

Obviously multiple scripts will use more system resources. Other than
that, it is really up to you.  If you are doing the same for all
processes then it makes the most sense to have one script.

Martin

Re: stap -x option

[Mike Mason]

Martin Hunt wrote:
> On Fri, 2007-07-27 at 13:59 -0400, Sanket Somnath Hase wrote:
>> Hi folks,
>>
>> a ) I was curious to know if we can provide more than one target to stap. 
>> Say I want to run the same script for more than one processes .
> 
> -x is probably not needed now that we handle command line args. However
> it is a nice complement to -c.

Both -x and -c are still needed.  They serve slightly different purposes.

Mike

Re: stap -x option

[William Cohen]

Sanket Somnath Hase wrote:
> Hi folks,
> 
> a ) I was curious to know if we can provide more than one target to stap. Say I want to run the same script for more than one processes .
> 
> b) Is there any benefit in running single script ( effectively single kernel module ) for all the processes under consideration  against running same script for each process individually ( and effectively  having many kernel modules which look for same set of events but for different targets ).
> 
> Looking forward to hear from you ,
> 
> Thanks ,
> Sanket
> 

It seems like one could have a begin probe parse a string argument with the list 
of pid interested in and enter them into a associative array using strtol and 
tokenize functions in a begin probe. Then have the probe check the associative 
array each time it fires. Maybe something like the attached script. This will 
need a newer version of systemtap that include the tokenize() function. The 
comment for syscall.read show how to check the associative array. Running the 
example something like this:

stap pids2watch.stp "124 456"
watching pids:
124
456


There are two issues with multiple probes. One is there will be additional 
overhead if there are more probes to run at a probe point. The other issue is 
that systemtap avoids recompiling the scripts when possible. It checks to see if 
a kernel module has been previously generated for a script, if so it reuses the 
module. If you attempt to use multiple instances of a script, systemtap may 
indicate that it can't load the module. The kernel only allow one instance of a 
module to be loaded into the kernel. You may need to resort to using the "-m" 
option to produce different modules to load.

-Will

Re: stap -x option

[Sanket Somnath Hase]

Will,
Thanks for the reply. However I have a  one question. 

" It checks to see if a kernel module has been previously
generated for a script, if so it reuses the module. If you attempt to use
multiple instances of a script, systemtap may indicate that it can't load
the module. "

a)
As per your above comments , if systemtap does reuse pre-existing modules for the same script , why should it even try loading module for one more such script ? Is there any threshold on the no of scripts that can reuse the same module ? And having crossed it systemtap tries to load a module ? 


b) I believe that the kernel module that is being loaded is the final outcome that will do the tracing activity. Even if I am running the same script multiple number of times but if I am using a different target , how is this info about different target getting passed , provided systemtap will reuse already loaded module ?  

Thanks ,
Sanket.


> Sanket Somnath Hase wrote:
>> Hi folks,
>> 
>> a ) I was curious to know if we can provide more than one target to
>> stap. Say I want to run the same script for more than one processes .
>> 
>> b) Is there any benefit in running single script ( effectively single
>> kernel module ) for all the processes under consideration  against
>> running same script for each process individually ( and effectively
>> having many kernel modules which look for same set of events but for
>> different targets ).
>> 
>> Looking forward to hear from you ,
>> 
>> Thanks , Sanket
>> 
> 
> It seems like one could have a begin probe parse a string argument with
> the list of pid interested in and enter them into a associative array
> using strtol and tokenize functions in a begin probe. Then have the probe
> check the associative array each time it fires. Maybe something like the
> attached script. This will need a newer version of systemtap that include
> the tokenize() function. The comment for syscall.read show how to check
> the associative array. Running the example something like this:
> 
> stap pids2watch.stp "124 456" watching pids: 124 456
> 
> 
> There are two issues with multiple probes. One is there will be
> additional overhead if there are more probes to run at a probe point. The
> other issue is that systemtap avoids recompiling the scripts when
> possible. It checks to see if a kernel module has been previously
> generated for a script, if so it reuses the module. If you attempt to use
> multiple instances of a script, systemtap may indicate that it can't load
> the module. The kernel only allow one instance of a module to be loaded
> into the kernel. You may need to resort to using the "-m" option to
> produce different modules to load.
> 
> -Will
> 
> 

Re: stap -x option

[Mike Mason]

William Cohen wrote:

[snip]

> 
> There are two issues with multiple probes. One is there will be 
> additional overhead if there are more probes to run at a probe point. 
> The other issue is that systemtap avoids recompiling the scripts when 
> possible. It checks to see if a kernel module has been previously 
> generated for a script, if so it reuses the module. If you attempt to 
> use multiple instances of a script, systemtap may indicate that it can't 
> load the module. The kernel only allow one instance of a module to be 
> loaded into the kernel. You may need to resort to using the "-m" option 
> to produce different modules to load.

While I think it's best to avoid running multiple instances of the same
script, it should still be allowed.  I ran into this yesterday when
I wanted to test the impact of running multiple instances of a script
I wrote.  Using -m to accomplish this is cumbersome.  Could we simply 
add an option that tells stap to ignore the cache?  It's simple, as 
the following diff shows:

Index: main.cxx
===================================================================
RCS file: /cvs/systemtap/src/main.cxx,v
retrieving revision 1.74
diff -r1.74 main.cxx
102a103
>     << "   -d         disable cache support" << endl
278c279
<       int grc = getopt (argc, argv, "hVMvtp:I:e:o:R:r:m:kgPc:x:D:bs:uq");
---
>       int grc = getopt (argc, argv, "hVMvtp:I:e:o:R:r:m:kgPc:x:D:bs:uqd");
311a313,316
>         case 'd':
>           s.use_cache = false;
>           break;
>

Then, if you run into module name conflicts, simply run stap with -d.

Mike

> 
> -Will

Re: stap -x option

[Frank Ch. Eigler]

Mike Mason <mmlnx@us.ibm.com> writes:

> [...]
> While I think it's best to avoid running multiple instances of the same
> script, it should still be allowed.  [...]
> Using -m to accomplish this is cumbersome.  

Please try again with the "-m"-related changes dsmith just checked in.

> Could we simply add an option that tells stap to ignore the cache?

It's not the caching per se that's the problem, but that the default
module name (stap_<getpid>) is reasonably unique but hard to express
with "-m".

Martin pointed out that load-time module renaming is an option too
(see "modprobe -o NAME MODULE").  A good solution could be to do this
automatically at staprun time.


- FChE