On Jul 11, 2011, at 12:39 PM, Nico Williams wrote: > 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).
Thanks. Three points: 1) A clarification: "The script you posted" is not my script. I'm not Scott, who posted the script, nor am I Scott's customer, who wrote the script. I'm just a member of the DTrace user community trying to be helpful. I happen to be an Oracle employee, but my involvement with Solaris and DTrace is strictly as a user. 2) The complaint is about "dynamic variable drops," so trace data from printf overrunning the principal buffer is not the issue in this particular case. 3) The script specified bufpolicy=ring. Unless I misunderstand the documentation, trace data should not generate drops with ring buffering, because it is always supposed to overwrite the oldest data. If I'm wrong about either of those last two points, I'm always happy to improve my understanding of DTrace. joe _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
