Unsuccessful with PTU 4.0 u3

Unsuccessful with PTU 4.0 u3

Imagen de tomscott

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

publicaciones de 10 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Dmitry Bazhin (Intel)

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

Imagen de julia-fedorova (Intel)

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

Imagen de tomscott

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

Imagen de Konstantin Lupach (Intel)

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

Imagen de julia-fedorova (Intel)

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

Imagen de Konstantin Lupach (Intel)

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.

Imagen de ethandavis157

thanks for support julia...

Imagen de tomscott

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

Imagen de tomscott

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

Inicie sesión para dejar un comentario.