|
Hello, I have a customer who has some dtrace questions. I am guessing that someone knows the answer to these, so I am asking here. Here are the questions: ********** In this document, we will describe how we assume that DTrace uses its memory. Most assumptions result from [1]. We want these assumptions to be validated by a DTrace expert from Oracle. This validation is necessary to provide us confidence that DTrace can execute for a long period of time (in the order of weeks) along with our software, without introducing errors due to e.g. “dynamic variable drops”. In addition, we described a problem we experience with our DTrace script, for which we want to have support from you. [1] Sun Microsystems inc, “Solaris Dynamic Tracing Guide”, September 2008. Quotes from Solaris Dynamic Tracing Guide [1], with interpretation: • “Each time the variable self->read is referenced in your D program, the data object referenced is the one associated with the operating system thread that was executing when the corresponding DTrace probe fired.” o Interpretation: Per CPU there is a dispatcher that has its own thread, when it executes the sched:::on-cpu and sched:::off probes. • “At that time, the ring buffer is consumed and processed. dtrace processes each ring buffer in CPU order. Within a CPU's buffer, trace records will be displayed in order from oldest to youngest.” Interpretation: There is a principal buffer per CPU 1) Impact on Business We have a number of assumptions that we would like to verify about DTrace. 2) What is the OS version and the kernel patch level of the system? SunOS nlvdhe321 5.10 Generic_141444-09 sun4v sparc SUNW,T5240 3) What is the Firmware level of the system? SP firmware 3.0.10.2.b SP firmware build number: 56134 SP firmware date: Tue May 25 13:02:56 PDT 2010 SP filesystem version: 0.1.22 ********** Thanks
|
_______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
