On Fri, Mar 18, 2022 at 5:11 PM Namhyung Kim <namhyung@xxxxxxxxxx> wrote: > > On Fri, Mar 18, 2022 at 3:07 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > On Fri, 18 Mar 2022 14:55:27 -0700 > > Namhyung Kim <namhyung@xxxxxxxxxx> wrote: > > > > > > > This looks a littl ugly ;-/ Maybe we can rename __down_common() to > > > > > ___down_common() and implement __down_common() as: > > > > > > > > > > static inline int __sched __down_common(...) > > > > > { > > > > > int ret; > > > > > trace_contention_begin(sem, 0); > > > > > ret = ___down_common(...); > > > > > trace_contention_end(sem, ret); > > > > > return ret; > > > > > } > > > > > > > > > > Thoughts? > > > > > > > > Yeah, that works, except I think he wants a few extra > > > > __set_current_state()'s like so: > > > > > > Not anymore, I decided not to because of noise in the task state. > > > > > > Also I'm considering two tracepoints for the return path to reduce > > > the buffer size as Mathieu suggested. Normally it'd return with 0 > > > so we can ignore it in the contention_end. For non-zero cases, > > > we can add a new tracepoint to save the return value. > > > > I don't think you need two tracepoints, but one that you can override. > > > > We have eprobes that let you create a trace event on top of a current trace > > event that can limit or extend what is traced in the buffer. > > > > And I also have custom events that can be placed on top of any existing > > tracepoint that has full access to what is sent into the tracepoint on not > > just what is available to the trace event: > > > > https://lore.kernel.org/all/20220312232551.181178712@xxxxxxxxxxx/ > > Thanks for the info. But it's unclear to me if it provides the custom > event with the same or different name. Can I use both of the original > and the custom events at the same time? I've read the code and understood that it's a separate event that can be used together. Then I think we can leave the tracepoint with the return value and let users customize it for their needs later. Thanks, Namhyung