mailing list of musl libc
 help / color / mirror / code / Atom feed
* Profiling musl
@ 2019-04-08 10:15 Pascal Felber
  2019-04-08 12:21 ` Rich Felker
  2019-04-08 12:57 ` Szabolcs Nagy
  0 siblings, 2 replies; 3+ messages in thread
From: Pascal Felber @ 2019-04-08 10:15 UTC (permalink / raw)
  To: musl

Dear all,

Does anyone have experience with profiling musl? We are running into 
performance issues (after modifying some of the musl code) and would 
like to understand where the overheads come from, but profiling with 
gprof does not work and we have issues with valgrind. Any help will be 
greatly appreciated.

Cheers,

Pascal


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Profiling musl
  2019-04-08 10:15 Profiling musl Pascal Felber
@ 2019-04-08 12:21 ` Rich Felker
  2019-04-08 12:57 ` Szabolcs Nagy
  1 sibling, 0 replies; 3+ messages in thread
From: Rich Felker @ 2019-04-08 12:21 UTC (permalink / raw)
  To: musl

On Mon, Apr 08, 2019 at 12:15:04PM +0200, Pascal Felber wrote:
> Dear all,
> 
> Does anyone have experience with profiling musl? We are running into
> performance issues (after modifying some of the musl code) and would
> like to understand where the overheads come from, but profiling with
> gprof does not work and we have issues with valgrind. Any help will
> be greatly appreciated.

I would use perf(1). Making gprof work has been a very low priority
(and maybe non-starter if the stuff needed for support would be
invasive) since its model inherently perturbs the performance
properties of the code badly.

Rich


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Profiling musl
  2019-04-08 10:15 Profiling musl Pascal Felber
  2019-04-08 12:21 ` Rich Felker
@ 2019-04-08 12:57 ` Szabolcs Nagy
  1 sibling, 0 replies; 3+ messages in thread
From: Szabolcs Nagy @ 2019-04-08 12:57 UTC (permalink / raw)
  To: musl

* Pascal Felber <pascal.felber@gmail.com> [2019-04-08 12:15:04 +0200]:
> Does anyone have experience with profiling musl? We are running into
> performance issues (after modifying some of the musl code) and would like to
> understand where the overheads come from, but profiling with gprof does not
> work and we have issues with valgrind. Any help will be greatly appreciated.

gprof is fairly intrusive anyway,
statistical profiling with perf should work
(perf record/perf report)

sometimes it's useful to trace/count some
points in the code, in principle debuggers
should be able to do it, but i don't know
a good tool for such thing (gdb is difficult
to automate and slow, unless you use ftrace
but that does not always work).
(i tried uprobe with perf probe, it does
system wide probing instead of just one
process and it's cumbersome to use)

you can always modify musl to add your own
instrumentation, since it's easy to run an
application with a modified musl:
 ./libc.so app
in some cases that does not work, then
 unshare -rm /bin/sh -c 'mount --bind libc.so /lib/ld-musl-$arch.so.1 && app'
or similar (the instrumentation code can
simply be dprintf(2,...)).


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-04-08 12:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-08 10:15 Profiling musl Pascal Felber
2019-04-08 12:21 ` Rich Felker
2019-04-08 12:57 ` Szabolcs Nagy

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).