From owner-soc-status@FreeBSD.ORG Sun Jun 15 17:58:13 2014 Return-Path: Delivered-To: soc-status@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C02794C for ; Sun, 15 Jun 2014 17:58:13 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (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 3E35B214B for ; Sun, 15 Jun 2014 17:58:13 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id w8so6170884qac.8 for ; Sun, 15 Jun 2014 10:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4LwfbzjhQoN2E6CgPUo4MGw634ucpCT6/KoeOnPixqg=; b=F04zPthLF+QcV47Z+ioo/UhNxcCD1K3er5Vw3zwH3glrNsBh6D/8T9iLMNvXAAkjBX xtv8eOh+9Mbni7CbdTdXyXlUbKM35/2FmSmuQXxSjzpjchPW1c6Q77qeeLKsFY2T/OZB gNwdRGexWCQ8tO1wmkqiXE2YhgQqrQjZnOXO4X+W1rNezXtpRHPi0rnxyEomDXDPEjtX KVF7EenJAYb6B0zncVJGCvLgxLx8X3ji5QeCZcB5oQ7u0ownD9ReILxWbkuhgcWcGsrG N60STwpu6kVSOKgnsOHABe0Da3nDJrBRgCReb32l0nqSXG4kmtMZiggC9HZxmhMgHehm i7wg== MIME-Version: 1.0 X-Received: by 10.140.101.18 with SMTP id t18mr3572856qge.108.1402855092398; Sun, 15 Jun 2014 10:58:12 -0700 (PDT) Received: by 10.140.84.85 with HTTP; Sun, 15 Jun 2014 10:58:12 -0700 (PDT) In-Reply-To: References: Date: Sun, 15 Jun 2014 20:58:12 +0300 Message-ID: Subject: Re: [GSOC] bhyve instruction caching From: Mihai Carabas To: soc-status@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: soc-status@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Summer of Code Status Reports and Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 17:58:13 -0000 On Sun, Jun 8, 2014 at 12:38 AM, Mihai Carabas wrote: >> >> These days I've started a discussion with Neel about some >> microbenchmarking mechanisms. I will come with some more details next >> week. > I've built a microbenchmarking kernel module which is accessing the > lapic->id for 1000000 and than I calculate the average of an access > (each access needs to be emulated by the hypervisor). > > I've also implemented the instuction caching mechanism. At each emulation: > - I check to see if I have that particular instruction cached > - if not I will cache it in a particula structure named "struct vie_cached" [1] > - if it's cached I just use that instruction > > Right now I am working on write-protecting the pages where the > instruction reside. I will come with some more details/results when I > finished this part too (there are some SMP issues I'm still debating > with Neel). I added the write protection for the pages where instruction resides (I mark them with PROT_READ|PROT_EXECUTE using vm_map_protect). When a page fault is raised on that page I delete the instruction from the cache. I've tested the instruction caching feature and it works ok (no bugs reveal). The results on the microbenchmarking are looking OK, but they aren't conclusive because I'm not write protecting the pages of the pagetable (which will eat more time). Right now for 1000000 accesses to the lapic-id we have an average of 6200 ticks per VM_EXIT for an instruction emulation. Without instruction caching the average is at about 10000ticks. Like I've said before, this results aren't very conclusive until I introduce all protections needed. I will come in the next weeks with more results when I have the caching feature fully implemented. I've also introduce a new systl to enable/disable instruction caching "hw.vmm.instruction_cache". Thanks, Mihai