From patchwork Thu Apr 21 21:58:07 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laszlo Ersek X-Patchwork-Id: 8904081 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id E67DABF29F for ; Thu, 21 Apr 2016 21:58:28 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id AD354202FF for ; Thu, 21 Apr 2016 21:58:27 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 06D9A202E9 for ; Thu, 21 Apr 2016 21:58:26 +0000 (UTC) Received: from localhost ([::1]:48751 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atMcD-0003J1-ED for patchwork-qemu-devel@patchwork.kernel.org; Thu, 21 Apr 2016 17:58:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atMc3-0003CM-Ld for qemu-devel@nongnu.org; Thu, 21 Apr 2016 17:58:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atMbz-0006Fi-5J for qemu-devel@nongnu.org; Thu, 21 Apr 2016 17:58:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54360) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atMby-0006FF-Sc for qemu-devel@nongnu.org; Thu, 21 Apr 2016 17:58:11 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE98E4DAF8; Thu, 21 Apr 2016 21:58:09 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-104.phx2.redhat.com [10.3.113.104]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3LLw7t5019116; Thu, 21 Apr 2016 17:58:08 -0400 To: Christoffer Dall References: <20160421162348.GA24178@cbox> From: Laszlo Ersek Message-ID: <57194CEF.3040202@redhat.com> Date: Thu, 21 Apr 2016 23:58:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160421162348.GA24178@cbox> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] Performance regression using KVM/ARM X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , Peter Maydell , Alexander Graf , qemu-devel@nongnu.org, "Michael S. Tsirkin" Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 04/21/16 18:23, Christoffer Dall wrote: > Hi, > > Commit 9fac18f (oslib: allocate PROT_NONE pages on top of RAM, > 2015-09-10) had the unfortunate side effect that memory slots registered > with KVM no longer contain a userspace address that is aligned to a 2M > boundary, causing the use of THP to fail in the kernel. > > I fail to see where in the QEMU code we should be asking for a 2M > alignment of our memory region. Can someone help pointing me to the > right place to fix this or suggest a patch? > > This causes a performance regssion of hackbench on KVM/ARM of about 62% > compared to the workload running with THP. > > We have verified that this is indeed the cause of the failure by adding > various prints to QEMU and the kernel, but unfortunatley my QEMU > knowledge is not sufficient for me to fix it myself. > > Any help would be much appreciated! Can you please test the attached series? (Note that I'm only interested in solving this problem as a productive distraction, so if the patches don't work, or require a lot of massaging for merging, I'll just drop them (or, preferably, give them to someone else).) Thanks Laszlo From 8e7cd9425417189f5fc894039a8af956ca2e19dd Mon Sep 17 00:00:00 2001 From: Laszlo Ersek Date: Thu, 21 Apr 2016 22:19:16 +0200 Subject: [PATCH 3/3] util/mmap-alloc: preserve size alignment with guard pages on ARM Commit 9fac18f03a90 ("oslib: allocate PROT_NONE pages on top of RAM") introduced a guard page after the user-requested area. (Commit 794e8f301a17 ("exec: factor out duplicate mmap code") factored out this logic, preserving the behavior of 9fac18f03a90.) Christoffer reports that 9fac18f03a90 renders the KVM/ARM performance optimization added in 2e07b297e0b4 ("oslib-posix: Align to permit transparent hugepages on ARM Linux") ineffective, because the single guard page makes the size of the region unaligned, preventing the application of THP. Restore 2e07b297e0b4 to working state by aligning the full area size -- consisting of user requested and guard pages -- on ARM. Ref: http://thread.gmane.org/gmane.comp.emulators.qemu/407833 Reported-by: Christoffer Dall Signed-off-by: Laszlo Ersek --- util/mmap-alloc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c index 41e36f74d7be..153a586cec63 100644 --- a/util/mmap-alloc.c +++ b/util/mmap-alloc.c @@ -41,7 +41,11 @@ size_t qemu_fd_getpagesize(int fd) static size_t size_with_guard_pages(size_t size, size_t align) { +#if defined(__arm__) + return QEMU_ALIGN_UP(size + getpagesize(), align); +#else return size + getpagesize(); +#endif } void *qemu_ram_mmap(int fd, size_t size, size_t align, bool shared) -- 1.8.3.1