Date: Sun, 4 Jan 2015 22:49:23 -0600 From: Bryan Venteicher <bryanv@daemoninthecloset.org> To: Jim Harris <jim.harris@gmail.com> Cc: Adrian Chadd <adrian@freebsd.org>, FreeBSD-current <freebsd-current@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: [CFT] Paravirtualized KVM clock Message-ID: <CAMo0n6R4CkE27_pFYhxSBuCqZhr1Xy8YCb9QBTBNHE8_Piv58w@mail.gmail.com> In-Reply-To: <CAJP=Hc9OpQu9tqLoPGiRwO5V1JKyzDD29qNCyRtqj-N03tTwRA@mail.gmail.com> References: <CAMo0n6QUp3iZ2fEqbrsD2MhEsWWOPTLisd9iB7TNEvbevcK0Fw@mail.gmail.com> <CAJ-Vmom3%2BB1Mckse0Pz7FYUdbmxb_rGjSno2jd4tARU18DT3_w@mail.gmail.com> <CAJP=Hc9OpQu9tqLoPGiRwO5V1JKyzDD29qNCyRtqj-N03tTwRA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 4, 2015 at 8:01 PM, Jim Harris <jim.harris@gmail.com> wrote: > > > 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 t= o > confirm. > > Yes =E2=80=8B - t=E2=80=8B hat's the main =E2=80=8B source=E2=80=8B . A similar issue exists in the network stack =E2=80=8BBPF.=E2=80=8B I haven't looked or thought too much if it make sense / is possible to use kvmclock in userland too (I think kib@ 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 cod= e > 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. KV= M >> > clock allows the guest to use the TSC instead; it is very similar to t= he >> > 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 existin= g >> > 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 timecounte= r >> > 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.or= g >> " >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMo0n6R4CkE27_pFYhxSBuCqZhr1Xy8YCb9QBTBNHE8_Piv58w>