On Mon, Jul 11, 2011 at 1:28 PM, Joe Pallas <pal...@cs.stanford.edu> wrote: > The script provided looks entirely reasonable. It uses one thread-local > variable which is set in sched:::on-cpu and cleared in sched:::off-cpu. > Honestly, the only way I can imagine this growing beyond the number of > hardware contexts is if there is a problem with the assumption that every > thread that fires on-cpu also fires off-cpu. And if that's the case, I would > indeed call that a bug.
Do your probe actions generate any trace data? If so then probe firing rate matters. Unless your probes are using destructive ops like chill() to the exclusion of any data-generating actions (including system()), and to the exclusion of any copyin() and friends, then your script can exhaust resources available to DTrace, leading to drops. The script you posted has a printf(), for example, which means that the probe in question generates data that can be dropped. The buffer into which the script's data get stored is a circular buffer -- if the consumer (the user-land part of DTrace) does not consume the data from that buffer fast enough then DTrace can drop traces. You can help prevent this (but not guarantee that it won't happen) by running the consumer at a higher priority than the victim process(es). Nico -- _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
