Date: Sun, 4 Jan 2015 19:01:18 -0700 From: Jim Harris <jim.harris@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: FreeBSD-current <freebsd-current@freebsd.org>, Bryan Venteicher <bryanv@daemoninthecloset.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: [CFT] Paravirtualized KVM clock Message-ID: <CAJP=Hc9OpQu9tqLoPGiRwO5V1JKyzDD29qNCyRtqj-N03tTwRA@mail.gmail.com> In-Reply-To: <CAJ-Vmom3%2BB1Mckse0Pz7FYUdbmxb_rGjSno2jd4tARU18DT3_w@mail.gmail.com> References: <CAMo0n6QUp3iZ2fEqbrsD2MhEsWWOPTLisd9iB7TNEvbevcK0Fw@mail.gmail.com> <CAJ-Vmom3%2BB1Mckse0Pz7FYUdbmxb_rGjSno2jd4tARU18DT3_w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 4, 2015 at 12:00 PM, Adrian Chadd <adrian@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. 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@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@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJP=Hc9OpQu9tqLoPGiRwO5V1JKyzDD29qNCyRtqj-N03tTwRA>