qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH PROTOTYPE 4/6] memory: Extend ram_block_discard_(require|disa


From: Peter Xu
Subject: Re: [PATCH PROTOTYPE 4/6] memory: Extend ram_block_discard_(require|disable) by two discard types
Date: Tue, 20 Oct 2020 15:17:06 -0400

On Thu, Sep 24, 2020 at 06:04:21PM +0200, David Hildenbrand wrote:
> We want to separate the two cases whereby
> - balloning drivers do random discards on random guest memory (e.g.,
>   virtio-balloon) - uncoordinated discards
> - paravirtualized memory devices do discards in well-known granularity,
>   and always know which block is currently accessible or inaccessible by
>   a guest. - coordinated discards
> 
> This will be required to get virtio_mem + vfio running - vfio still
> wants to block random memory ballooning.
> 
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Alex Williamson <alex.williamson@redhat.com>
> Cc: Wei Yang <richardw.yang@linux.intel.com>
> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>  exec.c                | 109 ++++++++++++++++++++++++++++++++++--------
>  include/exec/memory.h |  36 ++++++++++++--
>  2 files changed, 121 insertions(+), 24 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index e34b602bdf..83098e9230 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -4098,52 +4098,121 @@ void mtree_print_dispatch(AddressSpaceDispatch *d, 
> MemoryRegion *root)
>   * If positive, discarding RAM is disabled. If negative, discarding RAM is
>   * required to work and cannot be disabled.
>   */
> -static int ram_block_discard_disabled;
> +static int uncoordinated_discard_disabled;
> +static int coordinated_discard_disabled;

Instead of duplicating the codes, how about start to make it an array?

Btw, iiuc these flags do not need atomic operations at all, because all callers
should be with BQL and called majorly during machine start/reset.  Even not, I
think we can also use a mutex, maybe it could make things simpler.  No strong
opinion, though.

-- 
Peter Xu




reply via email to

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