[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: |
David Hildenbrand |
Subject: |
Re: [PATCH PROTOTYPE 4/6] memory: Extend ram_block_discard_(require|disable) by two discard types |
Date: |
Tue, 20 Oct 2020 21:58:34 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 |
On 20.10.20 21:17, Peter Xu wrote:
> 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.
>
I remember there were some !BQL users (but I might be confusing it with
postcopy code that once used to inhibit the balloon without BQL). Will
double-check. Simplifying it is certainly a good idea.
(we want to be able to check from virtio-balloon code repeatedly without
taking a mutex over and over again :) )
Thanks!
--
Thanks,
David / dhildenb