I was trying to aggregate on the stack trace of a CPU''s current thread from a cpu_t * and the best I could do was aggregating with sym() on the t_startpc field of the CPU''s current thread. It doesn''t look like it would be very difficult to write a new action to get stack() from a given CPU id. Would that be of interest to anyone else? If so, please let me know and I''ll write it up. Thanks, Rafael
On Fri, Aug 27, 2010 at 04:44:31PM -0700, Rafael Vanoni wrote:> I was trying to aggregate on the stack trace of a CPU''s current > thread from a cpu_t * and the best I could do was aggregating with > sym() on the t_startpc field of the CPU''s current thread. > > It doesn''t look like it would be very difficult to write a new > action to get stack() from a given CPU id. Would that be of interest > to anyone else? If so, please let me know and I''ll write it up.It is extremely difficult to do that from another CPU on SPARC, since register windows mean that much of the stack state is kept in-CPU. Even on x86, you can''t get anything better than the last place the thread updated its t_pcb (e.g. in cv_wait()), and there''s a good chance the stack won''t line up. Why do you need this? Could a global variable + a fast profile interrupt get you close enough: event-of-interest { interesting[blah->cpu->cpu_thread] = 1; } profile:::profile-4999, sched:::on-cpu, sched:::off-cpu /interesting[curthread]/ { interesting[curthread] = 0; @a[probename, stack()] = count(); } Cheers, - jonathan
On Mon, Aug 30, 2010 at 10:17:53AM -0700, Jonathan Adams wrote:> On Fri, Aug 27, 2010 at 04:44:31PM -0700, Rafael Vanoni wrote: > > I was trying to aggregate on the stack trace of a CPU''s current > > thread from a cpu_t * and the best I could do was aggregating with > > sym() on the t_startpc field of the CPU''s current thread. > > > > It doesn''t look like it would be very difficult to write a new > > action to get stack() from a given CPU id. Would that be of interest > > to anyone else? If so, please let me know and I''ll write it up. > > It is extremely difficult to do that from another CPU on SPARC, since > register windows mean that much of the stack state is kept in-CPU. Even > on x86, you can''t get anything better than the last place the thread updated > its t_pcb (e.g. in cv_wait()), and there''s a good chance the stack won''t line > up.Can''t this be done with dtrace_xcall()? BTW, another backtrace-like action I''d love to see would be something like ptree(), which would output ptree(1)-like output (but without program arguments) that could then be aggregated on. Nico --
On Mon, Aug 30, 2010 at 12:29:18PM -0500, Nicolas Williams wrote:> On Mon, Aug 30, 2010 at 10:17:53AM -0700, Jonathan Adams wrote: > > On Fri, Aug 27, 2010 at 04:44:31PM -0700, Rafael Vanoni wrote: > > > I was trying to aggregate on the stack trace of a CPU''s current > > > thread from a cpu_t * and the best I could do was aggregating with > > > sym() on the t_startpc field of the CPU''s current thread. > > > > > > It doesn''t look like it would be very difficult to write a new > > > action to get stack() from a given CPU id. Would that be of interest > > > to anyone else? If so, please let me know and I''ll write it up. > > > > It is extremely difficult to do that from another CPU on SPARC, since > > register windows mean that much of the stack state is kept in-CPU. Even > > on x86, you can''t get anything better than the last place the thread updated > > its t_pcb (e.g. in cv_wait()), and there''s a good chance the stack won''t line > > up. > > Can''t this be done with dtrace_xcall()?You can''t cross-call from probe context, let alone wait for one to complete. dtrace_xcall() is used by the dtrace infrastructure to ensure that any in-flight dtrace_probe()s while a state change was happening have completed before continuing on to the next step.> BTW, another backtrace-like action I''d love to see would be something > like ptree(), which would output ptree(1)-like output (but without > program arguments) that could then be aggregated on.That could be handy. Cheers, - jonathan
On 08/30/10 10:17 AM, Jonathan Adams wrote:> On Fri, Aug 27, 2010 at 04:44:31PM -0700, Rafael Vanoni wrote: >> I was trying to aggregate on the stack trace of a CPU''s current >> thread from a cpu_t * and the best I could do was aggregating with >> sym() on the t_startpc field of the CPU''s current thread. >> >> It doesn''t look like it would be very difficult to write a new >> action to get stack() from a given CPU id. Would that be of interest >> to anyone else? If so, please let me know and I''ll write it up. > > It is extremely difficult to do that from another CPU on SPARC, since > register windows mean that much of the stack state is kept in-CPU. Even > on x86, you can''t get anything better than the last place the thread updated > its t_pcb (e.g. in cv_wait()), and there''s a good chance the stack won''t line > up. > > Why do you need this? Could a global variable + a fast profile interrupt get > you close enough:I''d like to correlate the firing of a probe on one CPU with what another one is running. Yes, using a fast profile predicated on the right things can accomplish that as well. But in case more people were interested in a specific action, it would be cool to have one. Thanks, Rafael
On Mon, Aug 30, 2010 at 10:42:27AM -0700, Jonathan Adams wrote:> On Mon, Aug 30, 2010 at 12:29:18PM -0500, Nicolas Williams wrote: > > Can''t this be done with dtrace_xcall()? > > You can''t cross-call from probe context, let alone wait for one to complete. > > dtrace_xcall() is used by the dtrace infrastructure to ensure that any in-flight > dtrace_probe()s while a state change was happening have completed before > continuing on to the next step.Ah, thanks for the tip.> > BTW, another backtrace-like action I''d love to see would be something > > like ptree(), which would output ptree(1)-like output (but without > > program arguments) that could then be aggregated on. > > That could be handy.Yes, I think it would be, particularly for profiling apps with lots of short-lived processes, such as ON''s build :) Something like: profile-2 /uid == 12345/ { /* Need cwd since we don''t get program args */ @ptrees[ptree(), cwd] = count(); } Can one safely chase proc_t pointers in dtrace context? Nico --
On Mon, Aug 30, 2010 at 01:44:51PM -0500, Nicolas Williams wrote:> On Mon, Aug 30, 2010 at 10:42:27AM -0700, Jonathan Adams wrote: > > On Mon, Aug 30, 2010 at 12:29:18PM -0500, Nicolas Williams wrote: > > > Can''t this be done with dtrace_xcall()? > > > > You can''t cross-call from probe context, let alone wait for one to complete. > > > > dtrace_xcall() is used by the dtrace infrastructure to ensure that any in-flight > > dtrace_probe()s while a state change was happening have completed before > > continuing on to the next step. > > Ah, thanks for the tip. > > > > BTW, another backtrace-like action I''d love to see would be something > > > like ptree(), which would output ptree(1)-like output (but without > > > program arguments) that could then be aggregated on. > > > > That could be handy. > > Yes, I think it would be, particularly for profiling apps with lots of > short-lived processes, such as ON''s build :)Yeah, Nico and I were recently discussing a situation where a "stf_build package" of the EF test suite was taking about 5.5 hours on my workstation with a load avg. of .04. This is a situation where make is spawning a number of processes so having a ptree aggregation would be useful in profiling where the time is being spent at the process level. -- Will Fiveash Oracle http://opensolaris.org/os/project/kerberos/ Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/