Date: Mon, 26 Jan 2015 22:36:36 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Ryan Stone <rysto32@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Is anyone using the schedgraph.d script? Message-ID: <CAJ-Vmon=F4auUXo7zvj7L8wPB7de9yhq4VgPfsSNOHk5WDiCZA@mail.gmail.com> In-Reply-To: <CAFMmRNyDRwLQEgvtyOfXsKjt_NcPYw8Nf%2BYNuFas1O=vJw2F0g@mail.gmail.com> References: <CAJ-VmonoZ0bz2HRNi2s5yA7vNSeUAGjwnt80L8MBY9OOEz_9-w@mail.gmail.com> <CAJ-VmokZ7b1Wz0CsMdbjiVBwTQW_s78ePC2USE%2ByArzrMrbXbw@mail.gmail.com> <CAFMmRNyDRwLQEgvtyOfXsKjt_NcPYw8Nf%2BYNuFas1O=vJw2F0g@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On 26 January 2015 at 19:01, Ryan Stone <rysto32@gmail.com> wrote:
> Hm, there was one bug in that script. I uploaded a fixed version. The fix was:
>
> - printf("%d %d KTRGRAPH group:\"thread\", id:\"%s/%s tid %d\",
> state:\"runq add\", attributes: prio:%d, linkedto:\"%s/%s tid %d\"\n",
> cpu, timestamp, args[0]->td_proc->p_comm, args[0]->td_name,
> args[0]->td_tid, args[0]->td_priority, curthread->td_proc->p_comm,
> curthread->td_name, args[0]->td_tid);
> + printf("%d %d KTRGRAPH group:\"thread\", id:\"%s/%s tid %d\",
> state:\"runq add\", attributes: prio:%d, linkedto:\"%s/%s tid %d\"\n",
> cpu, timestamp, args[0]->td_proc->p_comm, args[0]->td_name,
> args[0]->td_tid, args[0]->td_priority, curthread->td_proc->p_comm,
> curthread->td_name, curthread->td_tid);
>
> Note that the last printf argument used args[0] instead of curthread
> as intended.
Cool! Thanks!
> One other thing that I have noticed with the schedgraph data gathering
> is that unlike KTR, in dtrace every CPU gathers its data into a
> CPU-local buffer. This can mean that a CPU that sees a large number
> of scheduler events will roll over its ring buffer much more quickly
> than a lightly loaded CPU. This can lead to a confusing or misleading
> schedgraph output at the beginning of the time period. You can
> mitigate this problem by allowing dtrace to allocate a larger ring
> buffer with:
>
> #pragma D option bufsize=32m
>
> (You can potentially tune it even higher than that, but that's a good
> place to start)
>
>
> Finally, I've noticed that schedgraph seems to have problems
> auto-detecting the clock frequency, so I tend to forcifully specify
> 1GHz (dtrace always outputs time in units of ns, so this is always
> correct to do with dtrace-gather data)
Good to know.
Is there any reason why this isn't just checked into -HEAD and -10?
-adrian
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmon=F4auUXo7zvj7L8wPB7de9yhq4VgPfsSNOHk5WDiCZA>