Re: [PATCH 02/12] trace-cmd: Add logic for TSC to nanosecond conversion

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 18 Mar 2021 05:42:47 +0200
Tzvetomir Stoyanov <tz.stoyanov@gmail.com> wrote:
> >
> > Your right. And I just tried this:
> >
> >  # trace-cmd record -C x86-tsc -e sched -B foo -C local -e sched sleep 1
> >
> > And it appears to ignore the -C local. Which I think is the right thing to
> > do ;-)  
> 
> According to the code, trace-cmd supports clock per instance. And it
> works, I tried this:
> 
> #trace-cmd record -C x86-tsc -e irq -B foo -C local -e sched sleep 1
> 
> and got different clocks:
>              <...>-290676 [006]1956659520918: softirq_exit:        ....
> foo:       zoom-10894 [004]112198623756671: sched_switch:  ....

Strange, I'll look at that again. It the report looked intermixed on my end
and seemed like it ignored the local clock.

> 
> although I cannot imagine a use case for this. It will be weird to
> visualise this by KerneShark.

Something I don't think we need to worry about now.

> 
> I think that we should introduce options per instance now,  as "-C
> tsc2nsec" cannot be implemented without it.
> I see two possible ways to implement it:
>  1. Break the current trace.dat file format by adding metadata for
> each instance.
>  2. Keep the current format and use nested options -  that's it, just
> another option "OPTION_INSTANCE". It will hold instance name and all
> options, specific for that instance, using the current options format.

Actually, we could simply extend the TRACECMD_OPTION_BUFFER. The way
options were designed was to be able to extend them. When an option is
read, it reads both the type and the size, and will skip over the size to
find the next option. If we extend the buffer option to include instance
options, all we need to do is check the size of the buffer option if it has
another item in it after the location of the buffer.

I'll look more into the code on this.

> 
> But there is one question, valid for both ways: What should be the
> scope for the global options ? Apply them only on the top instance, or
> they should be common for all instances ?

The way I usually handle this is, options are by default set for all
instances, and then the buffer instance can just override the defaults.

-- Steve