Re: [DynInst_API:] serial parseapi problem on aurora at ANL

[John Mellor-Crummey <johnmc@xxxxxxxx>]

Jim has a deleted account at Argonne. He could apply to have his account re-instated as part of the CSC250STTO11 project

Project title: 2.3.2.08 STTO11 HPCToolkit

--
John Mellor-Crummey Professor
Dept of Computer Science Rice University
email: johnmc@xxxxxxxx phone: 713-348-5179

On Oct 10, 2024, at 10:04 AM, Mark W. Krentel <krentel@xxxxxxxx> wrote:

Hi, does someone there have access to Aurora, the big machine at ANL?

We've found a 560 Meg MPI .so library that dyninst doesn't parse well,
too slow and serialized.

I run hpcstruct which calls ParseAPI::CodeObject::parse() which calls
ParseAPI::Parser::LaunchWork() which calls
ParseAPI::Parser::parse_frame() and then down to
InstructionAPI::Instruction::getCategory().

With 16 threads, it settles in with top reporting 100% CPU utilization
(only one core running), and gdb reports 15 threads stuck at futex_wait().

Both top and time(1) report max memory usage around 8 Gig.  The login
nodes have 1TB RAM, so it's not running into swap or anything.

It's not a new problem.  Dyninst 13.0 runs the same.

I was wondering if someone could take a look at this.
Aurora is still under NDA, so I'm being a bit guarded about details,
and I can't just copy the binary to another machine.
But if you can login to Aurora, then great.
If not, then we'll have to figure out something else.

--Mark



_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api