qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH RFC 17/21] migration: Rework ram discard logic for hugetlb do


From: Juan Quintela
Subject: Re: [PATCH RFC 17/21] migration: Rework ram discard logic for hugetlb double-map
Date: Wed, 01 Feb 2023 20:03:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Peter Xu <peterx@redhat.com> wrote:
> Hugetlb double map will make the ram discard logic different.
>
> The whole idea will still be the same: we need to a bitmap sync between
> src/dst before we switch to postcopy.
>
> When discarding a range, we only erase the pgtables that were used to be
> mapped for the guest leveraging the semantics of MADV_DONTNEED on Linux.
> This guarantees us that when a guest access triggered we'll receive a MINOR
> fault message rather than a MISSING fault message.
>
> Signed-off-by: Peter Xu <peterx@redhat.com>

Reviewed-by: Juan Quintela <quintela@redhat.com>
>                       length >> qemu_target_page_bits());
>      }
>  
> -    return ram_block_discard_range(rb, start, length);
> +    if (postcopy_use_minor_fault(rb)) {
> +        /*
> +         * We need to keep the page cache exist, so as to trigger MINOR
> +         * faults for every future page accesses on old pages.
> +         */
> +        return ram_block_zap_range(rb, start, length);
> +    } else {
> +        return ram_block_discard_range(rb, start, length);
> +    }

This is a question of style, so take it or leave as it as you wish.

You can change:

if (foo) {
    return X;
} else {
    return Y;
}

into:

if (foo) {
    return X;
}
return Y;

It is one line less of code, and in my eyes, makes it easier to see that
one exits in all cases.  But as said, this is a question of taste, and
that is as personal as it gets.

Later, Juan.




reply via email to

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