Re: [PATCH v32 0/5]Timestamp synchronization of host - guest tracing session

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Stefano,

On Sat, Mar 20, 2021 at 6:17 PM Stefano De Venuto
<stefano.devenuto99@xxxxxxxxx> wrote:
>
>
>
> On 3/20/21 7:25 AM, Tzvetomir Stoyanov wrote:
> > Hi Stefano,
> >
> > On Fri, Mar 19, 2021 at 7:44 PM Stefano De Venuto
> > <stefano.devenuto99@xxxxxxxxx> wrote:
> >>
> >>
> >> On 3/19/21 12:55 PM, Tzvetomir Stoyanov wrote:
> >>> Hi Stefano,
> >>>
> >>> On Fri, Mar 19, 2021 at 12:08 PM Stefano De Venuto
> >>> <stefano.devenuto99@xxxxxxxxx> wrote:
> >> Hi!
> >>>> The commands used to record are:
> >>>>
> >>>> Host:
> >>>> # trace-cmd record -C x86-tsc -e kvm:* -e msr:* -A tumbleweed:823 -e
> >>>> msr:* -C x86-tsc sleep 1
> >>> The guest trace clock is set automatically as the host, so this
> >>> command should be enough:
> >>> # trace-cmd record -C x86-tsc -e kvm:* -e msr:* -A tumbleweed:823 -e
> >>> msr:*  sleep 1
> >>>
> >>>> Guest:
> >>>> # echo x86-tsc > /sys/kernel/tracing/trace_clock
> >>> There is no need to set manually the guest clock, it will be
> >>> overwritten by trace-cmd agent.
> >>>
> >> Thanks so much for the proper way to do it, really appreciated.
> >>>> If necessary, I can provide more info about my setup, or do more tests.
> >>> Yes, please can you send me both host and guest trace files ?
> >> Here are the trace files, host and guest respectively:
> >>
> >> - http://xenbits.xen.org/people/dariof/tracing-examples/kvm/sync-kvmclock/trace.dat
> >> - http://xenbits.xen.org/people/dariof/tracing-examples/kvm/sync-kvmclock/trace-tumbleweed.dat
> >>
> >>> Also, it will be useful to send me the content of the KVM debug files:
> >>>     /sys/kernel/debug/kvm/<guest ID>/vcpu<*>/tsc-offset
> >> The guest has one vcpu (vcpu0) and the content of the file is:
> >>
> >> 255647917761327
> > Looks like there is a scaling between host and guest clocks in your
> > setup, not just a simple offset. We did not test yet our
> > implementation with scaling, although both offset and scaling are part
> > of the calculations. That makes your use case very valuable for us, as
> > we have an opportunity to test it now. And yes, looks like we have a
> > bug here.
> > Please, when you have time, can you repeat again the tracing session
> > and send again both trace files + the content of the KVM debug files:
> >      /sys/kernel/debug/kvm/<guest ID>/vcpu0/tsc-offset
> >      /sys/kernel/debug/kvm/<guest ID>/vcpu0/tsc-scaling-ratio
> > I'm asking to do a new trace, as most probably these offset and
> > scaling could be different now.
> Yes, the trace files are attached to this mail.
>
> The content of tsc-offset is:
> 453568564244284
>
> The content of tsc-scaling-ratio is:
> 4294967296
>
Just submitted the v33 of the patch set, added a check for a
non-default KVM scaling. Now it should work on your setup, as the KVM
scaling there looks to be the default. I didn't test it, as we have no
machine which supports KVM scaling. This is just a workaround, we have
to implement support to KVM scaling in our algorithm.
Please, can you test if it is OK ? Note, you have to apply  these
patch sets also, as there are dependencies:
   v2 Refactoring and improvements of time sync logic
   v4 TSC trace clock to nanosecond conversion

Thanks for testing this code!

>
> Thanks and Regards,
>
> Stefano
>
> >
> > Thanks!
> >
> >>>> Thanks and Regards,
> >>>>
> >>>> Stefano
> >>> Thanks for testing this code!
> >>>
> >> Thanks for your time,
> >>
> >> Stefano
> >
> >
>


-- 
Tzvetomir (Ceco) Stoyanov
VMware Open Source Technology Center



[Index of Archives]     [Linux USB Development]     [Linux USB Development]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux