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: stap -x option


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


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