Re: trace events

[Marek Bykowski <marek.bykowski@gmail.com>]

On Fri, 18 Nov 2022 16:22:26 -0700
Dave Jiang <dave.jiang@intel.com> wrote:

> 
> For kernel we are enabling trace events for CXL. But those events are 
> stemmed from hardware events. Ira is enabling CXL events defined by
> the CXL spec and emitted by the devices. Alison is enabling CXL
> events for poison data. And I'm enabling CXL events for PCIe AER
> errors.
> 
> But I think you want different type of events right? i.e. the flow of 
> the driver? I believe ftrace can enable function names for ftrace. Is 
> that what you are looking for?

Apology Dave, my bad. I'm so used to into people saying ftrace
in which they really mean the trace events that I thought you referred
to the latter, which of course isn't true as the two are separate.

Honestly I've never found a real use of the ftrace, except exercising,
as to me it is more a call trace and how a developer designs the SW
rather than how the HW is managed/interogated, but in the absence of the
trace events I re-thought and went down that path.

After a several attempts and finally setting the 'trace_clock'
to global I succeeded. With the 'trace_clock' set local (default)
I had only the last ftrace events logged in - don't know really why.
Actually the ./tools/bootconfig/scripts/ftrace2bconf.sh figured that
out for me walking through the ftrace settings I had configured after
booting the Linux up.

So now with a bootconfig as this
  kernel { trace_options =  sym-addr, hash-ptr, nofunc_stack_trace,
                   \nofunc-no-repeats 
           #trace_event = "module:*"
           trace_clock = global
           trace_buf_size = 2M
           ftrace = function_graph
           max_graph_depth = 5
           ftrace_filter = "*cxl*"
  } 

I'm seeing all the functions with *cxl*.

Thanks again.
Marek