On Sun, Jan 4, 2015 at 8:01 PM, Jim Harris <jim.harris_at_gmail.com> wrote: > > > On Sun, Jan 4, 2015 at 12:00 PM, Adrian Chadd <adrian_at_freebsd.org> wrote: > >> ... so, out of pure curiousity - what's making the benchmark go >> faster? Is it userland side of things calling clock methods, or >> something in the kernel, or both? >> >> > Most likely GEOM statistic gathering in the kernel but Bryan would have to > confirm. > > Yes - t hat's the main source . A similar issue exists in the network stack BPF. I haven't looked or thought too much if it make sense / is possible to use kvmclock in userland too (I think kib_at_ added fast gettimeofday & friends support a few years back). I intermittently saw this same kind of massive slowdown in nvme(4) > performance a couple of years back due to a bug in the TSC self-check code > which has since been fixed. The bug would result in falling back to HPET > and all of the clock calls from the GEOM code for each I/O would kill > performance. > > >> >> -adrian >> >> >> On 4 January 2015 at 09:56, Bryan Venteicher >> <bryanv_at_daemoninthecloset.org> wrote: >> > For the last few weeks, I've been working on adding support for KVM >> clock >> > in the projects/paravirt branch. Currently, a KVM VM guest will end up >> > selecting either the HPET or ACPI as the timecounter source. >> Unfortunately, >> > this is very costly since every timecounter fetch causes a VM exit. KVM >> > clock allows the guest to use the TSC instead; it is very similar to the >> > existing Xen timer. >> > >> > The performance difference between HPET/ACPI and KVMCLOCK can be >> dramatic: >> > a simple disk benchmark goes from 10K IOPs to 100K IOPs. >> > >> > The patch is attached is attached or available at [1]. I'd appreciate >> any >> > testing. >> > >> > Also as a part of this, I've tried to generalized a bit of our existing >> > hypervisor guest code, with the eventual goal of being able to support >> more >> > invasive PV operations. The patch series is viewable in Phabricator. >> > >> > https://reviews.freebsd.org/D1429 - paravirt: Generalize parts of the >> XEN >> > timer code into pvclock >> > https://reviews.freebsd.org/D1430 - paravirt: Add interface to >> calculate >> > the TSC frequency from pvclock >> > https://reviews.freebsd.org/D1431 - paravirt: Add simple hypervisor >> > registration and detection interface >> > https://reviews.freebsd.org/D1432 - paravirt: Add detection of bhyve >> using >> > new hypervisor interface >> > https://reviews.freebsd.org/D1433 - paravirt: Add detection of VMware >> using >> > new hypervisor interface >> > https://reviews.freebsd.org/D1434 - paravirt: Add detection of KVM >> using >> > new hypervisor interface >> > https://reviews.freebsd.org/D1435 - paravirt: Add KVM clock timecounter >> > support >> > >> > My current plan is to MFC this series to 10-STABLE, and commit a >> > self-contained KVM clock to the other stable branches. >> > >> > [1] - https://people.freebsd.org/~bryanv/patches/kvm_clock-1.patch >> > >> > _______________________________________________ >> > freebsd-arch_at_freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> > To unsubscribe, send any mail to "freebsd-arch-unsubscribe_at_freebsd.org" >> _______________________________________________ >> freebsd-current_at_freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org >> " >> > >Received on Mon Jan 05 2015 - 03:49:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:54 UTC