stack() for specified CPU

[Rafael Vanoni]

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

[Jonathan Adams]

Post by Rafael Vanoni
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

[Nicolas Williams]

Post by Jonathan Adams

Post by Rafael Vanoni
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
--

[Jonathan Adams]

Post by Nicolas Williams

Post by Jonathan Adams

Post by Rafael Vanoni
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.

Post by Nicolas Williams
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

[Nicolas Williams]

Post by Jonathan Adams

Post by Nicolas Williams
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.

Post by Jonathan Adams

Post by Nicolas Williams
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
--

[Will Fiveash]

Post by Nicolas Williams

Post by Jonathan Adams

Post by Nicolas Williams
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.

Post by Jonathan Adams

Post by Nicolas Williams
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.

[Rafael Vanoni]

Post by Jonathan Adams

Post by Rafael Vanoni
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

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