site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com ---------------- ------- fbt probe sched ---------------- ------- compute_averages sleep thread_unblock wakeup thread_continue on-cpu thread_dispatch on-cpu thread_dispatch off-cpu ---------------- ------- -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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: 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. This email sent to site_archiver@lists.apple.com