On Tue, Aug 19, 2008 at 04:26:51PM -0400, Brian Utterback wrote:
> I have been doing some profiling using the profile provider. I have a 
> command that runs more slowly on the T1000 than it does on prior 
> systems and I am trying to find out why. Using the profile provider at 
> 1000 hz, and aggregating on the ustack output, I find that the same 

As a side note, it's generally better to use a prime rate, like 997 hz,
instead of something which is a multiple of the clock rate.

> function appears at the top of the stack on both platforms, but on 
> each there are specific instruction locations within the function that 
> appear most often and these are different on the two platforms. They 
> are consistent on a platform. That is when I re-run the test on one 
> platform, about 4 specific PC locations will appear in the top spots, 
> but on that platform it is always the same 4 and the 4 are different 
> between the platforms.
> 
> So, I am trying to figure out whether or not there is something 
> special happening at those locations, or just before or just after, or 
> are they just artifacts of how the profile provider works? There are 
> two function calls with this function, but neither set of 4 locations 
> seem to be near the calls. And if the time was really spent inside the 
> next lower down level, wouldn't that have been reflected in the ustack 
> output?

The top frame of ustack() in a profile probe with a zero "arg0" (i.e. a probe
that fired while the user code was executing) will be the interrupted
instruction.  Without more information about what the "platform"s you speak
of are (different x86 boxes?  intel v.s. AMD?  intel v.s. sparc?), it's
hard to say much.

Some snippets of disassembly would help, if you can provide them.  Something
like:

        echo "the_line_from_the_ustack_output+0xoffset ::dis" | mdb -p program

would give you ten instructions on either side of the location.  Otherwise,
could you provide some information on what the interrupted locations are
doing?

Cheers,
- jonathan

_______________________________________________
dtrace-discuss mailing list
[email protected]

Reply via email to