Re: Measuring semaphore contention times with markers

[Mike Mason <mmlnx at us dot ibm dot com>]

Frank Ch. Eigler wrote:
> Mike Mason <mmlnx@us.ibm.com> writes:
>
> > FWIW... Here's a simple example of using markers to measure
> > semaphore contention times.  I don't claim that it's complete or
> > efficient, just an example of an area where markers are useful.
>
> Indeed.  (The equivalent systemtap script should be more compact.)
>
> In order for upstream to consider including these sorts of valuable
> markers, they'll want to have some benchmarks.  Most important is
> bound to be the overall slowdown caused by dormant markers, and second
> would be the increase in code (.text) size.  Of lesser interest might
> be the slowdown caused by a minimal marker handler that just returns.
> Can you or someone else run some tests?

OK, understood.  Has anyone benchmarked markers in general?  Any suggestions on how to run a benchmark that will be acceptable to the kernel community?

> > This was originally written by a colleague to use kprobes.  It
> > probes in the middle of functions in some cases.  The kprobes
> > version hard coded those probe point addresses, requiring the
> > addresses to be updated for each kernel.  [...]
>
> How hard did you try to use symbolic kernel.statement("*@file:line)
> probes?  Would some of the outlined improvements (.relative and such)
> in bugzilla have helped?

I didn't try at all.  Any solution that relies on line numbers or relative positions will be difficult to maintain, as we already know.  I thought that's one of the reasons we want markers.

Mike

> - FChE