From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 04:49:45 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 860F3B3F for ; Mon, 5 Jan 2015 04:49:45 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7B819DA for ; Mon, 5 Jan 2015 04:49:45 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id y20so19010089ier.32 for ; Sun, 04 Jan 2015 20:49:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=19nMuSJjgms/sP+RScuQsC3HdrI3WazmNhVjDevVAgI=; b=az15LwxJQdfxxiLsGfKX0mobBN1oW6J7s9PcEQbd+BLarE2yj4ymxpDXCovXYOWjs9 k+J2CcrduttVqTH2wemO4+Tfqu761Fx3XFjGDV9Qwnw3b4hqMVncEFBBovU2PRXLUFrh paRGRQLiy27Hy9eLe8L3J7HLCcLflpzpypki9lLvC7cvzKKlxsmcQ6X6bgfk2guYCTnr brmUPq8lmQjxOmt6CigA152EykU4706x84p6+Bp3JfMnFeT3rQcDDZ5KhpTmYJ4WHLQ9 /56NsFDj7Hu0rcD6r4rU9C15J0WfA3SS7XEHeYRlQHe3Usvaj7Hl9TnBeq8aRf32PFZt 3TGw== X-Gm-Message-State: ALoCoQkokw6svyFNlV4j1hCiDPluwVstHTzhmNhjyJJ1XRjYqtq1aGWNRaVPnFISAXV/BuUhJPWA X-Received: by 10.50.7.34 with SMTP id g2mr9297153iga.36.1420433383960; Sun, 04 Jan 2015 20:49:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.217 with HTTP; Sun, 4 Jan 2015 20:49:23 -0800 (PST) X-Originating-IP: [72.177.7.16] In-Reply-To: References: From: Bryan Venteicher Date: Sun, 4 Jan 2015 22:49:23 -0600 Message-ID: Subject: Re: [CFT] Paravirtualized KVM clock To: Jim Harris Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , FreeBSD-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 04:49:45 -0000 On Sun, Jan 4, 2015 at 8:01 PM, Jim Harris wrote: > > > On Sun, Jan 4, 2015 at 12:00 PM, Adrian Chadd 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 >> 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 >> " >> > >