15:44 <fedeztk_> Hi, I'm a new systemtap user. I'm sorry if this is a simple/stupid question, but how should I migrate my systemtap script (and its probes) to a specific CPU? This should happen periodically, so I opted for a timer probe where i called the system function and doing something like that:

15:44 <fedeztk_> system(sprintf("taskset -a --pid --cpu-list %lu %lu >/dev/null", next_cpu, pid()))

15:45 <serhei> Hmm. As I understand it, the systemtap probes run on the same CPU as the events they're probing?

15:46 <fedeztk_> Yes, I'm running a benchmark on cpu X and in my systemtap script I need to be on the same CPU in order to read meaningful data

15:47 <serhei> Hmm. Which types of probes are you using in your script?

15:48 <fche> fedeztk_, note that the taskset command itself will be run some time later, possibly on a separate cpu from that of the probe

15:49 <fedeztk_> serhei, I use 2 timer probes and also the scheduler.ctxswitch

15:49 <fche> fedeztk_, suggest also printing out the command or the next_cpu field to ensure the correct number is being passed

15:51 <fedeztk_> I already checked that and it seems to be correct. As for the latency of the system function I knew that from the language manual, but that shouldn't be a problem since when I record data I check the cpu again

15:51 <serhei> hmm. If the probes aren't specific to the program, you could check cpu() inside the probe and only record data if it matches the CPU where the benchmark is running?

15:51 <serhei> assuming I understand your question correctly

15:52 <serhei> if the benchmark migrates from CPU to CPU you'd have to adjust the value you're checking cpu() against

15:54 <fedeztk_> yes, that's an option too but I was looking for a way to migrate from one cpu to another. It works when I start the script because I managed to get both my benchmark process and my systemtap script to start on the same cpu, but when I need to switch to the next cpu -for both the benchmark and the script- I'm 'lost". Hope it is more clear now

15:55 <fedeztk_> The benchmark doesn't migrate on itself between CPUs, my goal is to force it to migrate together with my systemtap script

15:55 <fche> fedeztk_, what you have there looks like it should work, if the rate of taskset changes is small

16:00 <fedeztk_> Ok, thank you. I'll investigate on that again. So just as a confirm, systemtap doesn't provide any built-in function to migrate the current script and in general a particular process from one CPU to another?

16:00 <fche> there is no such thing as migrating a stap script

16:00 <fche> it runs systemwide all the time as/where the events occur

16:00 <fche> timers e.g. might fire on whatever cpu the kernel sees fit

16:01 <fche> re. migrating a task from cpu to cpu --- no there's no tapset function for that I'm aware of, so system(taskset ...) seems right

16:01 <fche> just racy, in case you want to frequently change it

16:02 <fedeztk_> Ok, so I'm in the right direction

16:03 <fche> I think so!

21:52 <LeoB> After I build systemtap from git, install it an try to run a simple stp, step 5 staprun returns: NONE/libexec/systemtap/stapio: No such file or directory

21:52 <LeoB> is that a known issue?

21:55 <LeoB> Pass 5: starting run. \n NONE/libexec/systemtap/stapio: No such file or directory \n WARNING: /usr/local/bin/staprun exited with status: 1

21:57 <LeoB> I thought it was some issue on generating the correct path, but then I ran `sed -i 's/NONE/\/usr/' /usr/local/bin/staprun`, but there was another error:

21:58 <LeoB> stapio:init_relayfs:353: ERROR: ncpus=40, bulkmode = 0 \n stapio:init_relayfs:354: ERROR: This is inconsistent! Please file a bug report. Exiting now.\n ERROR: Cannot attach to module stap_a9384f4d225052a3dc78252f754d04_186126 control channel; not running? \n ERROR: 'stap_a9384f4d225052a3dc78252f754d04_186126' is not a zombie systemtap module.

22:29 <fche> LeoB, that NONE tells me something was weird about hwo it was configured

22:30 <fche> try configure --prefix=$INSTALLATION_DIRECTORY ; make all install

22:30 <fche> you don't want to edit binaries with sed, that way lies madness :)