Regarding schedgraph.d
abhishek kulkarni
abhya007 at gmail.com
Thu Jul 9 19:38:44 UTC 2015
Hello,
I got some very good inputs from you for writing a script that gives the
total running time for a particular thread as well as the total time that
the particular thread was off cpu. That script is working fine. Now, I want
to extend that script for a system wide performance. I need the "running
times" and the " off cpu times" for each thread. So, the script should
summarize the results at the end of the script for each thread. Is it
possible to achieve that using Dtrace and if yes, how. If no, would it need
a python like script to summarize the results threadwise. Please find the
attached script for a single thread.
Regards
Abhishek Kulkarni
On Sun, Jul 5, 2015 at 5:48 PM, abhishek kulkarni <abhya007 at gmail.com>
wrote:
> Thanks mark. I will go through all the references mentioned. your answer
> gives a clear picture of how the sched provider differs for FreeBSD.
>
> Thanks and Regards
> Abhishek Kulkarni
>
> On Sun, Jul 5, 2015 at 4:32 PM, Mark Johnston <markj at freebsd.org> wrote:
>
>> On Thu, Jul 02, 2015 at 07:40:21PM -0400, Ryan Stone wrote:
>> > The best that I can offer right now is the Illumos documentation:
>> >
>> > http://dtrace.org/guide/chp-sched.html
>>
>> I wrote and committed some DTrace provider man pages a little while ago.
>> The page for the sched provider is here:
>>
>> https://www.freebsd.org/cgi/man.cgi?query=dtrace-sched&sektion=4&apropos=0&manpath=FreeBSD+11-current
>>
>> >
>> > The caveat is that the types documented there are not implemented in
>> > FreeBSD. Where illumos uses a lwpsinfo_t, FreeBSD uses a struct thread:
>> >
>> >
>> https://svnweb.freebsd.org/base/head/sys/sys/proc.h?revision=284215&view=markup#l206
>> >
>> > psinfo_t is replaced by struct proc.
>> >
>> >
>> https://svnweb.freebsd.org/base/head/sys/sys/proc.h?revision=284215&view=markup#l495
>> >
>> > cpuinfo_t* arguments are not implemented and passed as NULL. You can
>> > access the current cpu number using the "cpu" variable.
>> >
>> >
>> > Finally, the schedctl-* probes don't apply to the FreeBSD scheduler and
>> > therefore are unimplemented.
>>
>> I removed them in r281702: our sched provider uses FreeBSD types and
>> thus is already incompatible with the Solaris/illumos sched provider, so
>> it didn't make much sense to me to keep them around.
>>
>> >
>> >
>> > On Thu, Jul 2, 2015 at 12:30 PM, abhishek kulkarni <abhya007 at gmail.com>
>> > wrote:
>> >
>> > > Thanks Ryan. Those are some very useful tips. Ill get on with trying
>> all
>> > > of those and get back If I have some more concerns. Also, could you be
>> > > having some document which has some logical description about the
>> "sched"
>> > > probes for FreeBSD, which could give details like when is the
>> particular
>> > > probe fired, the probe's arguments etc. Thanks again.
>> > >
>> > > Regards
>> > > Abhishek Kulkarni
>> > >
>> > > On Wed, Jul 1, 2015 at 1:51 PM, Ryan Stone <rysto32 at gmail.com> wrote:
>> > >
>> > >> On Tue, Jun 30, 2015 at 7:11 PM, abhishek kulkarni <
>> abhya007 at 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 */
>> > >> }
>> > >>
>> > >>
>> > >
>> > _______________________________________________
>> > freebsd-dtrace at freebsd.org mailing list
>> > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace
>> > To unsubscribe, send any mail to "
>> freebsd-dtrace-unsubscribe at freebsd.org"
>>
>
>
-------------- next part --------------
#pragma D option quiet
#pragma D option bufpolicy=ring
BEGIN
{
flag=0;
times_offcpu=0;
cpustart[cpu] = 0;
times_oncpu=0;
flag1=0;
}
sched:::off-cpu
/execname =="ping"/
{
self->ts = timestamp;
self->next_thread = args[0]->td_tid;
printf("taken off the cpu,The next thread to run is : %d\n", self->next_thread);
flag=2;
}
sched:::on-cpu
/execname=="ping" && flag ==2/
{
/*self->delta += (timestamp - self->ts)/1000;*/
times_oncpu+=(timestamp-self->ts)/1000;
/* printf("the time off-cpu was : %d micro-seconds\n",self->delta); */
flag=0;
}
sched:::enqueue
/ execname =="ping"/
{
printf("added to the runq at %Y\n", timestamp);
}
sched:::dequeue
/args[0]->td_name =="ping"/
{
printf("removed from the runq at %Y\n",timestamp);
}
sched:::off-cpu
/cpustart[cpu] && execname =="ping" && flag1==1/
{
/* save elapsed */
times_oncpu += (timestamp - cpustart[cpu])/1000;
flag1=0;
}
/* Record the start time of a thread */
sched:::on-cpu,
sched:::remain-cpu
/execname == "ping"/
{
printf("thread running\n");
cpustart[cpu] = timestamp;
flag1=1;
}
END
{
printf("-------XXX---------\nthe total time off cpu is : %d\n",times_offcpu);
printf("The total running time for the thread is :%d\n",times_oncpu);
}
More information about the freebsd-dtrace
mailing list