From patchwork Fri Apr 22 10:34:27 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoffer Dall X-Patchwork-Id: 613532 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 ozlabs.org (Postfix) with ESMTPS id 3qrsSq6HLfz9t0t for ; Fri, 22 Apr 2016 20:35:07 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b=Si5SdCik; dkim-atps=neutral Received: from localhost ([::1]:58899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atYQT-00083q-Px for incoming@patchwork.ozlabs.org; Fri, 22 Apr 2016 06:35:05 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48612) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atYPp-0006Mq-85 for qemu-devel@nongnu.org; Fri, 22 Apr 2016 06:34:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atYPm-0000uE-Hd for qemu-devel@nongnu.org; Fri, 22 Apr 2016 06:34:25 -0400 Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:35262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atYPm-0000u6-05 for qemu-devel@nongnu.org; Fri, 22 Apr 2016 06:34:22 -0400 Received: by mail-wm0-x22e.google.com with SMTP id e201so13689372wme.0 for ; Fri, 22 Apr 2016 03:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=YMhilUB6wGOFMhpZI3EgM04wlnUAQcgJOU25JzxpSDo=; b=Si5SdCikEXsEZJGwOaHgwS1LytzeuEQRXW6cOJu57nNoJzopRA2ZDcIKYsEu6DtKDN 2oLLwNxdRyKcrBBalvE+8pOtZPCafmASuvpZ/AiYXg/q+8rL3mbegNOQlNYoVhwDNH8p qB+LEGCz7QeTQrRF40YSxuYx7NxG0/WHxw6fs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=YMhilUB6wGOFMhpZI3EgM04wlnUAQcgJOU25JzxpSDo=; b=F5y81RId9dKHWWUsF/pDEhqBRHkqpjvDYIb4CQyDtAzvHFupVrQ36Y3ofRABRByNBd efxS1gE7xPnd3t1Apyv6a0C4U3FhMgERg+ses9QNTqEHux5/SkVqwoY7dIBYl7ktrmas fTRPuRpj3jU4I8OT6SqMjkBovNpdYalIhCQzEUhufRUj/xo1VaTfMZLwEz+EsT2cNIiS 1O7bwxSmrfAjb5s5j1TuiEg7G9h/1wV21WF/Gou8HLwsmc17KhZrnPiEPLIYrGB9qBC2 ZtswYTss1Lktn2vYM4aOzS0FRD7qCizkVhFs1QHD9lro3E78Susa2sYqRas1pPFBVzQC EPBA== X-Gm-Message-State: AOPr4FXlQdU5PE60/yYErWymnkfZeCdi/SiAkNNBPNZEcaUUs7yZFVwkiE0r4+AHwRD14hif X-Received: by 10.194.74.231 with SMTP id x7mr19060581wjv.60.1461321261325; Fri, 22 Apr 2016 03:34:21 -0700 (PDT) Received: from localhost.localdomain ([94.18.191.146]) by smtp.gmail.com with ESMTPSA id h8sm2706561wmd.2.2016.04.22.03.34.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Apr 2016 03:34:20 -0700 (PDT) From: Christoffer Dall To: qemu-devel@nongnu.org Date: Fri, 22 Apr 2016 12:34:27 +0200 Message-Id: <1461321267-32747-1-git-send-email-christoffer.dall@linaro.org> X-Mailer: git-send-email 2.1.2.330.g565301e.dirty X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22e Subject: [Qemu-devel] [PATCH] util: align memory allocations to 2M on AArch64 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: Peter Maydell , "Michael S. Tsirkin" , Marc Zyngier , Alexander Graf , Christoffer Dall , Laszlo Ersek , shihwei@cs.columbia.edu Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" For KVM to use Transparent Huge Pages (THP) we have to ensure that the alignment of the userspace address of the KVM memory slot and the IPA that the guest sees for a memory region have the same offset from the 2M huge page size boundary. One way to achieve this is to always align the IPA region at a 2M boundary and ensure that the mmap alignment is also at 2M. Unfortunately, we were only doing this for __arm__, not for __aarch64__, so add this simply condition. This fixes a performance regression using KVM/ARM on AArch64 platforms that showed a performance penalty of more than 50%, introduced by the following commit: 9fac18f (oslib: allocate PROT_NONE pages on top of RAM, 2015-09-10) We were only lucky before the above commit, because we were allocating large regions and naturally getting a 2M alignment on those allocations then. Reported-by: Shih-Wei Li Signed-off-by: Christoffer Dall --- util/oslib-posix.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/util/oslib-posix.c b/util/oslib-posix.c index d25f671..03b055e 100644 --- a/util/oslib-posix.c +++ b/util/oslib-posix.c @@ -35,7 +35,7 @@ extern int daemon(int, int); #endif -#if defined(__linux__) && (defined(__x86_64__) || defined(__arm__)) +#if defined(__linux__) && (defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)) /* Use 2 MiB alignment so transparent hugepages can be used by KVM. Valgrind does not support alignments larger than 1 MiB, therefore we need special code which handles running on Valgrind. */