Unsuccessful with PTU 4.0 u3

Unsuccessful with PTU 4.0 u3

I have been using PTU 3.2 with success on Nehalem EPs and switched to PTU 4.0 u3 so that I could profile Nehalem EXs. So far I've been unsuccessful.

The kernel is RHEL5 (Linux 2.6.18-128.el5) and the sep3 and pax drivers build and install. The "vtsarun -cl" command runs and lists the processor as I74. But when using the eclipse interface to run experiments, vtdpview cores and the last lines of the console are:
...
17:09:07.538 Processing module 33 / 45 (dgraph458357)
17:09:14.712 Processing module 33 / 45 (dgraph458357)

This last module turns out to be the module of interest.

Any thoughts on what is wrong?

Going back to PTU 3.2 is not an option as we are using EXs now.

Thanks,

Tom

10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Tom,

We have not seen this during testing on NHM-EX, so it seems to be application-specific. To investigate such issues we usually need the experiment directory and problematic binaries. The list of such binaries can be obtained by removing the binaries from your workload one by one and re-running the conversion (try vtsaview --re-convert). We'll contact you directly to look into this.

Thanks,

Dmitry

Tom,

sometimes there might be an issue with PTU loop discovery algorithm.

To check this - can you please try

$ export PTU_NOT_PROCESS_LOOPS=1
$ <>/vtdpview --re-convert

and tell us if the last command was successful

thanks

Julia

Hi Julia,

I ran:

$ export PTU_NOT_PROCESS_LOOPS=1
$ vtdpview /localdisk/tscott/workspacePTU40/NoLaunch/General-Exploration-2010-09-29-11-46-43 --re-convert

The vtdpview segfaulted while processing module 42 / 53, which was the program that I was profiling.

I can provide a gdb backtrace of the vtdpview core if you'd like.

Thanks,

Tom

Tom, that would be helpful. However, the our binaries are stripped and we will not get much info from stack.
As Dmitry wrote in his message to investigate this issue we need problematic binaries and experiment directory. All problematic binaries can be detected by removing crashing binary and running experiment conversion again:
vtdpview exp --re-convert

Kostya,
Tom provided gdb trace - i will take a look if smth could be learnt from it.

Tom,
we don't need core - so no worries.

look for vtdpview.log or vtsaview.log in the experiment directory after you --re-convert that experiment

thanks

julia

Information provided by Tom (many thanks for cooperation!) helped us to localize and fix the issue.
If somebody has similar problems please let us know in a different thread of this forum.

thanks for support julia...

I didn't mean to leave this thread dangling. As Konstantin reported, the patch provided in October had solved our problem and we have been successfullyusing PTU 4.0 u3 on Nehalem EX processors since. Thank you for the quick turn around you provided us in October. - Tom

I didn't mean to leave this thread dangling. As Konstantin reported, the patch provided in October had solved our problem and we have been successfullyusing PTU 4.0 u3 on Nehalem EX processors since. Thank you for the quick turn around you provided us in October. - Tom

Leave a Comment

Please sign in to add a comment. Not a member? Join today