From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:52017)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <satoru.moriya.br@hitachi.com>) id 1UUUEA-0000vi-MZ
	for qemu-devel@nongnu.org; Mon, 22 Apr 2013 23:49:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <satoru.moriya.br@hitachi.com>) id 1UUUE8-0004Gm-1n
	for qemu-devel@nongnu.org; Mon, 22 Apr 2013 23:49:10 -0400
Received: from mail7.hitachi.co.jp ([133.145.228.42]:40598)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <satoru.moriya.br@hitachi.com>) id 1UUUE7-0004GH-Ix
	for qemu-devel@nongnu.org; Mon, 22 Apr 2013 23:49:07 -0400
Message-ID: <5176044D.4090809@hitachi.com>
Date: Tue, 23 Apr 2013 12:47:25 +0900
From: Satoru Moriya <satoru.moriya.br@hitachi.com>
MIME-Version: 1.0
References: <5174C7AA.5040701@hp.com>
In-Reply-To: <5174C7AA.5040701@hp.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v4] Add option to mlock qemu and guest
	memory
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Chegu Vinod <chegu_vinod@hp.com>
Cc: qemu-devel qemu-devel <qemu-devel@nongnu.org>

Hi Vinod,

Thank you for your report.

(2013/04/22 14:16), Chegu Vinod wrote:
> FYI... I had tried to use this change earlier and it did show some
> improvements in perf. (due to reduced exits).
>
> But as expected mlockall () on large sized guests adds a considerable
> delay in boot time. 

Yes, it is expected.

> For e.g. on an 8 socket Westmere box => a 256G guest :
> took an additional ~2+ mins to boot and a 512G guest took an additional
> ~5+ mins to boot. This is mainly due to long time spent in trying to clear
> all the pages.
>
>     77.96%         35728  qemu-system-x86  [kernel.kallsyms]     [k] clear_page_c
>             |
>             --- clear_page_c
>                 hugetlb_no_page
>                 hugetlb_fault
>                 follow_hugetlb_page
>                 __get_user_pages
>                 __mlock_vma_pages_range
>                 __mm_populate
>                 vm_mmap_pgoff
>                 sys_mmap_pgoff
>                 sys_mmap
>                 system_call
>                 __GI___mmap64
>                 qemu_ram_alloc_from_ptr
>                 qemu_ram_alloc
>                 memory_region_init_ram
>                 pc_memory_init
>                 pc_init1
>                 pc_init_pci
>                 main
>                 __libc_start_main
>
> Need to have a faster way to clear pages.

Hmm, clear_page() just calls memset(page, 0, PAGE_SIZE)...
The patch has just merged today. I'll start to think of the issue above.

Regards,
Satoru