This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: @defined in schedtimes.stp
On Wed, 2010-11-03 at 12:02 +0100, Joachim Worringen wrote:
> Am 03.11.2010 11:36, schrieb Mark Wielaard:
> > wget http://sourceware.org/systemtap/ftp/releases/systemtap-1.3.tar.gz
> > tar zxf systemtap-1.3.tar.gz
> > cd systemtap-1.3
> > ./configure --prefix=/usr/local/systemtap
> > make
> > sudo make install
> >
> > And then just use the stap binary from /usr/local/systemtap/bin
>
> Works perfectly this way. Is it generally sufficient to just install the
> kernel-debuginfo packages, and then the systemtap tarball?
Yes, it should be. And optionally any debuginfo packages for any user
space you want to inspect more closely with specific user space probes
if wanted.
> [root@x8dth-1 systemtap]# /usr/local/systemtap/bin/stap schedtimes.stp
> all mode
> execname: pid run(us) sleep(us) io_wait(us) queued(us)
> total(us)
>
> init: 1 6 3549288 0 3
> 3549297
> migration/0: 2 3 3027334 0 3
> ....
>
> Now for the results: what I want to figure out with this script is
> whether there are situations where a thread (user space, in my case)
> wants to run, but has to wait to be scheduled on a CPU. This should
> exactly be what the "queued" column contains, right?
Yes, I believe that is what the script measures with QUEUED. It notices
a task got sched_switch out, and if it was still in a runnable state it
will measure how long it will be waiting in the run queue to get
sched_switch back in.
Cheers,
Mark