Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Callsite representation (avoid pointing to wrappers.c) #9

Closed
artpol84 opened this issue Jun 6, 2019 · 5 comments
Closed

Callsite representation (avoid pointing to wrappers.c) #9

artpol84 opened this issue Jun 6, 2019 · 5 comments

Comments

@artpol84
Copy link
Contributor

artpol84 commented Jun 6, 2019

For the following application (ring_c.txt), I have to set the stack depth:

export MPIP="-k 2")

To see the actual callsites and get the following output:

---------------------------------------------------------------------------
@--- Callsites: 6 ---------------------------------------------------------
---------------------------------------------------------------------------
 ID Lev File/Address        Line Parent_Funct             MPI_Call
  1   0 wrappers.c           515 MPI_Barrier              Barrier
  1   1 ring_c.c              81 main
  2   0 wrappers.c           515 MPI_Barrier              Barrier
  2   1 ring_c.c              78 main
  3   0 wrappers.c          6649 MPI_Recv                 Recv
  3   1 ring_c.c              52 main
  4   0 wrappers.c          7608 MPI_Send                 Send
  4   1 ring_c.c              60 main
  5   0 wrappers.c          6649 MPI_Recv                 Recv
  5   1 ring_c.c              71 main
  6   0 wrappers.c          7608 MPI_Send                 Send
  6   1 ring_c.c              39 main

An entry in the wrapper.c as it points to mpiP (profiler tool) internals that are irrelevant to the application being analyzed.
Does it make sense to always shift one stack frame up to skip wrappers.c?

@artpol84
Copy link
Contributor Author

artpol84 commented Jun 7, 2019

Clarification: this is with libunwind

@artpol84
Copy link
Contributor Author

artpol84 commented Jun 7, 2019

#10 seems to fix the issue for me.
Though I noticed the following comment:

// Inlining / noinlining may affect frames in report
//   - Tools frames may appear in report

I'm not sure if this is a concern here: mpiP can control whether or not it's functions are inlined. It is possible to have a NO_INLINE macro that will restrict compiler from inlining functions that are capturing stack.

Anyway, I believe that other variants of stack capturing are using this approach, so I assume it is safe to use it here as well.

@artpol84
Copy link
Contributor Author

artpol84 commented Jun 26, 2019

#10 turned to be incorrect.
As the replacement, I opened #14.
As opposed to indirectly guessing how many frames to skip, this commit is attacking it directly: search for the MPI_op in the stacktrace to identify the beginning of what should be reported.

@artpol84
Copy link
Contributor Author

artpol84 commented Jun 26, 2019

Current version report

With -O0 optimization

---------------------------------------------------------------------------
@--- Callsites: 3 ---------------------------------------------------------
---------------------------------------------------------------------------
 ID Lev File/Address          Line Parent_Funct             MPI_Call
  1   0 wrappers.c            6218 MPI_Isend                Isend
  1   1 7-nonblock-waitall.c    47 func1
  1   2 7-nonblock-waitall.c    53 func2
  1   3 7-nonblock-waitall.c    57 func3
  1   4 7-nonblock-waitall.c    64 main
  2   0 wrappers.c            5558 MPI_Irecv                Irecv
  2   1 7-nonblock-waitall.c    46 func1
  2   2 7-nonblock-waitall.c    53 func2
  2   3 7-nonblock-waitall.c    57 func3
  2   4 7-nonblock-waitall.c    64 main
  3   0 wrappers.c            8995 MPI_Waitall              Waitall
  3   1 7-nonblock-waitall.c    48 func1
  3   2 7-nonblock-waitall.c    53 func2
  3   3 7-nonblock-waitall.c    57 func3
  3   4 7-nonblock-waitall.c    64 main

wrappers.c are captured for every MPI op.

With -O3 optimization

---------------------------------------------------------------------------
@--- Callsites: 3 ---------------------------------------------------------
---------------------------------------------------------------------------
  1   0 7-nonblock-waitall.c    48 func1                    Waitall
  1   1 7-nonblock-waitall.c    53 func2
  1   2 7-nonblock-waitall.c    57 func3
  1   3 7-nonblock-waitall.c    64 main
  2   0 wrappers.c            6218 MPI_Isend                Isend
  2   1 7-nonblock-waitall.c    47 func1
  2   2 7-nonblock-waitall.c    53 func2
  2   3 7-nonblock-waitall.c    57 func3
  2   4 7-nonblock-waitall.c    64 main
  3   0 7-nonblock-waitall.c    46 func1                    Irecv
  3   1 7-nonblock-waitall.c    53 func2
  3   2 7-nonblock-waitall.c    57 func3
  3   3 7-nonblock-waitall.c    64 main

wrappers.c is captured for Isend but not for others (build was with -O3).

With #14 (for both -O0 and -O3 optimizations)

---------------------------------------------------------------------------
@--- Callsites: 3 ---------------------------------------------------------
---------------------------------------------------------------------------
 ID Lev File/Address        Line Parent_Funct             MPI_Call
  1   0 7-nonblock-waitall.c    46 func1                    Irecv
  1   1 7-nonblock-waitall.c    53 func2
  1   2 7-nonblock-waitall.c    57 func3
  1   3 7-nonblock-waitall.c    64 main
  2   0 7-nonblock-waitall.c    48 func1                    Waitall
  2   1 7-nonblock-waitall.c    53 func2
  2   2 7-nonblock-waitall.c    57 func3
  2   3 7-nonblock-waitall.c    64 main
  3   0 7-nonblock-waitall.c    47 func1                    Isend
  3   1 7-nonblock-waitall.c    53 func2
  3   2 7-nonblock-waitall.c    57 func3
  3   3 7-nonblock-waitall.c    64 main

@artpol84
Copy link
Contributor Author

Addressed by #14 that was merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant