Regarding schedgraph.d

[Ryan Stone]

The best that I can offer right now is the Illumos documentation:

http://dtrace.org/guide/chp-sched.html

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.


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 */
>> }
>>
>>
>