Re: [PATCH v12 08/11] perf tools: Minimal CALLCHAIN_DEFERRED support

[Steven Rostedt]

On Wed, 2 Jul 2025 14:23:24 +0200
Jens Remus <jre...@linux.ibm.com> wrote:

> > +struct perf_record_callchain_deferred {
> > +   struct perf_event_header header;  
> 
> At minimum the timestamp field added to perf with "[PATCH v12 07/11]
> perf: Support deferred user callchains for per CPU events" needs to be
> added here as well:

Thanks for the review.

> 
>       __u64                    timestamp;
> 
> Otherwise this and any subsequent enhancements of the perf tools do no
> longer work at all.  But probably the timestamp field also needs to be
> used for some purpose?

OK, so this may be part of the discussion about using this as a
timestamp. The timestamp is the timestamp given by the deferred trace
infrastructure. It holds the time that this stack trace is valid for.
But that's assuming that the timestamp is the same as what perf is
using.

In case of dropped events, we could have the case of:

  system_call() {
    <nmi> {
      take kernel stack trace
      ask for deferred trace.

   [EVENTS START DROPPING HERE]
    }
    Call deferred callback to record trace [ BUT IS DROPPED ]
  }

  system_call() {
    <nmi> {
      take kernel stack trace
      ask for deferred trace [ STILL DROPPING ]
    }
    [ READER CATCHES UP AND STARTS READING EVENTS AGAIN]

    Call deferred callback to record trace
  }

The user space tool will see that kernel stack traces of the first
system call, then it will see events dropped, and then it will see the
deferred user space stack trace of the second call.

If the timestamps are in sync with perf and what is passed in, then the
tool will see that the kernel stack traces from the first system call
are older than the timestamp of the user stack trace and know that they
are not related.

Without either saving the timestamp along with the kernel stack traces,
or having the timestamps in sync, user space will not know whether or
not if the user space stack trace of the second system call belongs to
the kernel stack traces that were recorded in the first system call.

I guess the question is, do we just not associate stack traces beyond
where events are dropped? If so, we don't even need to save the
timestamp.

-- Steve


> 
> > +   __u64                    nr;
> > +   __u64                    ips[];
> > +};