qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 16/16] postcopy: Add doc about hugepages and


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH v2 16/16] postcopy: Add doc about hugepages and postcopy
Date: Fri, 24 Feb 2017 17:12:52 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0

On 06/02/2017 18:33, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" <address@hidden>
> 
> Signed-off-by: Dr. David Alan Gilbert <address@hidden>
> ---
>  docs/migration.txt | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/docs/migration.txt b/docs/migration.txt
> index 6503c17..b462ead 100644
> --- a/docs/migration.txt
> +++ b/docs/migration.txt
> @@ -482,3 +482,16 @@ request for a page that has already been sent is 
> ignored.  Duplicate requests
>  such as this can happen as a page is sent at about the same time the
>  destination accesses it.
>  
> +=== Postcopy with hugepages ===
> +
> +Postcopy now works with hugetlbfs backed memory:
> +  a) The linux kernel on the destination must support userfault on hugepages.
> +  b) The huge-page configuration on the source and destination VMs must be
> +     identical; i.e. RAMBlocks on both sides must use the same page size.
> +  c) Note that -mem-path /dev/hugepages  will fall back to allocating normal
> +     RAM if it doesn't have enough hugepages, triggering (b) to fail.
> +     Using -mem-prealloc enforces the allocation using hugepages.
> +  d) Care should be taken with the size of hugepage used; postcopy with 2MB
> +     hugepages works well, however 1GB hugepages are likely to be problematic
> +     since it takes ~1 second to transfer a 1GB hugepage across a 10Gbps 
> link,
> +     and until the full page is transferred the destination thread is 
> blocked.
> 
Reviewed-by: Laurent Vivier <address@hidden>




reply via email to

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