qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Performance regression using KVM/ARM


From: Alexander Graf
Subject: Re: [Qemu-devel] Performance regression using KVM/ARM
Date: Fri, 22 Apr 2016 13:24:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 04/22/2016 01:16 PM, Andrew Jones wrote:
On Fri, Apr 22, 2016 at 12:26:52PM +0200, Christoffer Dall wrote:
On Fri, Apr 22, 2016 at 11:17:47AM +0100, Peter Maydell wrote:
On 22 April 2016 at 11:15, Christoffer Dall <address@hidden> wrote:
Peter just pointed me to a change I remember doing for ARM, so perhaps
this fix is the right one?


diff --git a/util/oslib-posix.c b/util/oslib-posix.c
index d25f671..a36e734 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. */
I hadn't realised AArch64 didn't define __arm__. Your extra clause
wants to be inside the parens for the ||, not outside.

So was the problem just that we weren't passing 2MB as the align
parameter to qemu_ram_mmap(), and if we do pass 2MB then it does the
right thing ?

Yes, that was essentially the problem.  I'll send a proper patch.

However, Marc pointed out, that we should probably think about improving
on this in the future, because if you're running on a 64K page system
and want huge pages, you have to align at a higher boundary, but I'm on
the other hand not sure such a boundary is always practical on a 64K
system.  Which would suggest that we either need to:

1) Probe the kernel for the page size and always align to something that
allows huge pages, or

2) Let the user specify an option that says it wants to be able to use
THP and only then align to the huge page boundary.

Not sure...
Probably (1), otherwise the T in THP becomes t, i.e. the use of THP
gets slightly less transparent. Though I agree that using THP on 64k
page systems isn't always a good choice, I think, in those cases,
that users would likely just disable THP for the whole system.

I'd say that THP on 64k systems really only makes sense with support for combined pages that allows you to use 2MB huge pages on a 64k PAGE_SIZE system. So in that case aligning to 2MB is fine again.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]