Re: dtrace: catching thread yield
Re: dtrace: catching thread yield
- Subject: Re: dtrace: catching thread yield
- From: Terry Lambert <email@hidden>
- Date: Tue, 25 Aug 2009 17:42:57 -0700
On Aug 25, 2009, at 3:26 PM, Joel Reymont wrote:
I would like to get a kernel stack trace whenever a thread yields.
This may explain why the tread is yielding.
This is done with the sched provider on Solaris but is there a way
to do it on the Mac?
I thought of thread_yield_internal in the fbt provider but it didn't
fire when tried.
Threads generally don't yield; they either block, or they are
involuntarily preempted. The following routines fbt probes will
correspond roughly to the following subset of sched provider routines:
---------------- -------
fbt probe sched
---------------- -------
compute_averages sleep
thread_unblock wakeup
thread_continue on-cpu
thread_dispatch on-cpu
thread_dispatch off-cpu
---------------- -------
Note that for some of them, Mach will have discarded the kernel stack
on exit. Also, the "on-cpu" is for the new thread (if there is one)
and the "off-cpu" is for the old thread, so you will have to
introspect the arguments, assuming they are available, in order to
decode what's happening (the actualy switch takes place in
thread_invoke, which is static to keep you from putting fbt probes on
it; it gets inlined from thread_run and thread_block_reason).
Generally, the overhead of the kernel still using type 1 probes and
therefore needing to marshal and convert arguments to the probe-
expected types that look like the Solaris types meant that the cost
was too high to implement the sched provider in any performance path.
Digging the onformation out of the functions themselves is going to
mean you reading the xnu source code.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden