Measuring semaphore contention times with markers

[Mike Mason]

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