Date: Wed, 1 Jul 2015 16:51:02 -0400 From: Ryan Stone <rysto32@gmail.com> To: abhishek kulkarni <abhya007@gmail.com> Cc: Ryan Stone <rstone@freebsd.org>, "freebsd-dtrace@freebsd.org" <freebsd-dtrace@freebsd.org> Subject: Re: Regarding schedgraph.d Message-ID: <CAFMmRNwu8SoX-dJPb1wBh26UnXAnM5x7FZprDmXpVXbS7htkYQ@mail.gmail.com> In-Reply-To: <CAJUVsesOHQegeS=yfED8iKUoJK5KEVnLBqKH1MpSUuH_4i=_RQ@mail.gmail.com> References: <CAJUVsesOHQegeS=yfED8iKUoJK5KEVnLBqKH1MpSUuH_4i=_RQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jun 30, 2015 at 7:11 PM, abhishek kulkarni <abhya007@gmail.com>
wrote:
> Hello Ryan,
>
> I was looking to schedgraph.d . I need to modify the script for a single,
> particular thread. I atleast need to know the thread transitions, as in the
> context switches for the particular thread and also the different states
> for a single thread. Could you please help with the filters that I need to
> add in order to use the script for a single thread or else suggest me just
> the nexessary probes that I could use for writing a new script for a single
> thread .
>
> Regards
> Abhishek Kulkarni
>
There are a couple of things that you could filter on, depending on what
you know about the thread of interest. The "execname" variable gives the
name of the current process. If you're interesting in tracing a
single-threaded process, that would be an option. Another variable of
interest would be the "curthread" variable. This gives a pointer to the
"struct thread" for the current thread. One field that you could trace on
would be curthread->td_tid. You can use ps to find your thread id and then
run the script as:
dtrace -s script.d <tid>
And in the script, filter with / curthread->td_tid == $1 /. Another field
that you could use would be curthread->td_name, which contains the name of
the current thread. If your application names threads with
"pthreads_set_name_np()", then that name will appear in td_name and you can
filter based off of that.
An alternative approach would be to use a thread-local variable. If you
know that your thread is the only thread that might hit a probe, you can
set a thread local variable in that probe and filter on it later on. For
example, if your thread is the only thread that will call a function called
foobar() in the kernel, you could do this:
fbt::foobar:entry
{
self->interesting = 1;
}
sched:::off-cpu
/ self->interesting /
{
/* trace interesting data here */
}
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNwu8SoX-dJPb1wBh26UnXAnM5x7FZprDmXpVXbS7htkYQ>