[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH RFC 17/21] migration: Rework ram discard logic for hugetlb double-map,
Juan Quintela <=