Skip site navigation (1)Skip section navigation (2)
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>