On Thu, Mar 11, 2021 at 4:44 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > Hi Tzvetomir, > > I took a look at the following options: > > trace-cmd record : --date , --ts-offset > > trace-cmd report : --ts-offset , --ts2secs > > And thought about how this will be affected by the the new host-guest > sync, and the tsc2nsecs. > > Note, all of this is if the user does not specify -C on the record command > line. If the user specifies a clock, then only the host-guest in this is > done, but the tsc2nsecs is *not* performed. > > 1) trace-cmd record --date > > man page: > > --date > With the --date option, "trace-cmd" will write timestamps into > the trace buffer after it has finished recording. It will then > map the timestamp to gettimeofday which will allow wall time > output from the timestamps reading the created trace.dat file. > > My thought is this: > > raw time stamp (what is recorded in each event) > > + host-guest sync (for guest trace.dat files) > > + tsc2nsecs > > + conversion to wall time. In the following command: trace-cmd record --date -e kvm -A GuestVM -e all --date We have in the host trace file: - conversion to wall time, based on the raw TSC clock - conversion of raw TSC to nanoseconds I think it does not make sense to apply conversion to wall time on the nanoseconds, as this --date offset is according to the raw TSC, not to the corresponding nanoseconds ? In the guest is even more complicated, as we have: - conversion to wall time, based on the raw guest TSC clock - host-guest sync, which converts guest TSC to host TSC - conversion of raw host TSC to nanoseconds We cannot apply 'conversion to wall time' based on the guest raw TSC on the final result where we have guest events in nanoseconds (based on host TSC) > > That is, the --date will work on the raw time stamp plus the conversion to > host and then to nanoseconds, and then convert that to wall time. > > 2) trace-cmd record --ts-offset > > > man page: > > --ts-offset offset > Add an offset for the timestamp in the trace.dat file. This will > add a offset option into the trace.dat file such that a > trace-cmd report will offset all the timestamps of the events by > the given offset. The offset is in raw units. That is, if the > event timestamps are in nanoseconds the offset will also be in > nanoseconds even if the displayed units are in microseconds. > > I think we can do the same thing as with the --date. > > raw time stamp (what is recorded in each event) > > + host-guest sync (for guest trace.dat files) > > + tsc2nsecs (only if -C is not specified) > > + add offset. > > > 3) trace-cmd report --ts-offset > > man page: > > --ts-offset offset > Add (or subtract if negative) an offset for all timestamps of > the previous data file specified with -i. This is useful to > merge sort multiple trace.dat files where the difference in the > timestamp is known. For example if a trace is done on a virtual > guest, and another trace is done on the host. If the host > timestamp is 1000 units ahead of the guest, the following can be > done: > > trace-cmd report -i host.dat --ts-offset -1000 -i guest.dat > > This will subtract 1000 timestamp units from all the host events as it merges > with the guest.dat events. Note, the units is for the raw units recorded in > the trace. If the units are nanoseconds, the addition (or subtraction) from > the offset will be nanoseconds even if the displayed units are microseconds. > > > Again, I think we can do the following: > > raw time stamp (what is recorded in each event) > > + host-guest sync (for guest trace.dat files) > > + tsc2nsecs (only if in trace.dat files) > > + add offset (in nano seconds if -C was not specified in record) > > > The rationale is that is that we should be processing what the user sees. > If they see nanoseconds (regardless if its truncated to microseconds) then > the --ts-offset should be in nanoseconds. > > 4) trace-cmd report --ts2secs > > man page: > > --ts2secs HZ > Convert the current clock source into a second (nanosecond > resolution) output. When using clocks like x86-tsc, if the > frequency is known, by passing in the clock frequency, this will > convert the time to seconds. > > This option affects any trace.dat file given with *-i* proceeding it. > If this option comes before any *-i* option, then that value becomes > the default conversion for all other trace.dat files. If another > --ts2secs option appears after a *-i* trace.dat file, than that option > will override the default value. > > Example: On a 3.4 GHz machine > > trace-cmd record -p function -C x86-tsc > > trace-cmd report --ts2ns 3400000000 > > The report will convert the cycles timestamps into a readable second > display. The default display resolution is microseconds, unless *-t* > is used. > > The value of --ts-offset must still be in the raw timestamp units, even > with this option. The offset will be converted as well. > > > This is the one exception, and done differently. But I think we should > still process the host-guest conversion first. But when this specified, > then it overrides the tsc2nsecs in the trace.dat file. > > raw time stamp (what is recorded in each event) > > + host-guest sync (for guest trace.dat files) > > + use --ts2secs instead of tsc2nsecs > > > 5) trace-cmd report --ts2secs --ts-offset > > Now if someone were to add both --ts2secs and --ts-offset, we should do the > same as --ts-offset and replace the tsc2nsecs with what is in the --ts2secs. > > raw time stamp (what is recorded in each event) > > + host-guest sync (for guest trace.dat files) > > + use --ts2secs instead of tsc2nsecs > > + add offset (in nano seconds if -C was not specified in record) > > > Does this make sense? > > Dario, feel free to comment on this as well. The host-guest is the > information stored in each guest file that tells it how its TSC matches the > host (if -C is not used in the record). The ts2nsecs is done on the host > where it reads the perf data to find out how the kernels converts the TSC > to nanoseconds, and this information is stored in each trace.dat file (host > and guest). This email is about how those will affect the current options > listed above. > > Thanks! > > -- Steve -- Tzvetomir (Ceco) Stoyanov VMware Open Source Technology Center
|