[DTrace-devel] [PATCH v4] Implement the lockstat provider

[Nick Alcock]

On 25 May 2023, Kris Van Hees via DTrace-devel stated:

> On Wed, May 24, 2023 at 08:17:45PM -0400, Eugene Loh via DTrace-devel wrote:
>> Why does lockstat not report a function (e.g., dtrace -lP lockstat)?  I
>> thought that some probes instrumented source code (e.g., lockstat) and
>> therefore reported a module and function; others (like profile, cpc, dtrace)
>> did not and therefore did not. It appears that lockstat is reporting a
>> module but not a function, but clearly lockstat is instrumenting source
>> code.
>
> No, lockstat is not instrumenting source code.  It is providing probes that
> allow instrumentation of locking primitives in the kernel.  The fact that the
> legacy version reported multiple probes (each with a function name listed) for
> SDT probes is simply an artifact of the implementation requiring multiple
> probes locations for the same (conceptual) probe.  That is no longer needed
> because we overlay multiple probe locations with a single probe.  Which is
> perfectly valid because we are not probing location but rather logic.

Rather than going off on semantics, it's worth asking: is there any
situation in which it would be useful for a user to probe a specific set
of locking calls in one kernel function and not another? It seems to me
that doing that is only going to run the risk of missing locks -- what
you should be doing in that situation is probing the locking calls and
conditionalizing on the *lock used*, not the function it's being locked
from.

(But possibly doing the latter might be easier -- it's a useful proxy
for specific locks, or sets of locks, in some situations, and doesn't
require you to dig out the sets of locks in question, which in some
situations might be very difficult indeed. So it's a bit of a shame we
can't bring the function names back somehow.)

-- 
NULL && (void)