From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atXuO-0004BF-Nn for qemu-devel@nongnu.org; Fri, 22 Apr 2016 06:02:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atXuK-0007fP-AY for qemu-devel@nongnu.org; Fri, 22 Apr 2016 06:01:56 -0400 Received: from mail-wm0-x233.google.com ([2a00:1450:400c:c09::233]:38367) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atXuK-0007f3-4L for qemu-devel@nongnu.org; Fri, 22 Apr 2016 06:01:52 -0400 Received: by mail-wm0-x233.google.com with SMTP id u206so18697898wme.1 for ; Fri, 22 Apr 2016 03:01:51 -0700 (PDT) Date: Fri, 22 Apr 2016 12:02:00 +0200 From: Christoffer Dall Message-ID: <20160422100200.GE25288@cbox> References: <20160421162348.GA24178@cbox> <57194CEF.3040202@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57194CEF.3040202@redhat.com> Subject: Re: [Qemu-devel] Performance regression using KVM/ARM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Peter Maydell , "Michael S. Tsirkin" , qemu-devel@nongnu.org, Marc Zyngier , Alexander Graf Hi Laszlo, On Thu, Apr 21, 2016 at 11:58:07PM +0200, Laszlo Ersek wrote: > 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).) > I like your procrastination methods! Unfortunately this fix wasn't the right one either. -Christoffer