Re: [PATCH RFC 1/3] locking: Add contended_release tracepoint

[Google]

On Wed,  4 Mar 2026 16:56:15 +0000
Dmitry Ilvokhin <d@xxxxxxxxxxxx> wrote:

> Add the contended_release trace event. This tracepoint fires on the
> holder side when a contended lock is released, complementing the
> existing contention_begin/contention_end tracepoints which fire on the
> waiter side.
> 
> This enables correlating lock hold time under contention with waiter
> events by lock address. Subsequent patches wire this tracepoint into
> the individual lock implementations.
> 

OK, but I don't recommend you to split the traceevent definition
and its usage. Could you combine [1/3] and [3/3], so that we can
understand why this event is introduced and where it is recorded
by checking one commit?

Thank you,

> Signed-off-by: Dmitry Ilvokhin <d@xxxxxxxxxxxx>
> ---
>  include/trace/events/lock.h | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
> 
> diff --git a/include/trace/events/lock.h b/include/trace/events/lock.h
> index 8e89baa3775f..4f28e41977ec 100644
> --- a/include/trace/events/lock.h
> +++ b/include/trace/events/lock.h
> @@ -138,6 +138,23 @@ TRACE_EVENT(contention_end,
>  	TP_printk("%p (ret=%d)", __entry->lock_addr, __entry->ret)
>  );
>  
> +TRACE_EVENT(contended_release,
> +
> +	TP_PROTO(void *lock),
> +
> +	TP_ARGS(lock),
> +
> +	TP_STRUCT__entry(
> +		__field(void *, lock_addr)
> +	),
> +
> +	TP_fast_assign(
> +		__entry->lock_addr = lock;
> +	),
> +
> +	TP_printk("%p", __entry->lock_addr)
> +);
> +
>  #endif /* _TRACE_LOCK_H */
>  
>  /* This part must be outside protection */
> -- 
> 2.47.3
> 


-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>