[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5efd931f-9d69-2936-89e8-278fe106616d@redhat.com>
Date: Wed, 3 Feb 2021 14:44:20 +0100
From: David Hildenbrand <david@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>,
"Maciej S. Szmigiero" <mail@...iej.szmigiero.name>,
Sean Christopherson <seanjc@...gle.com>
Cc: Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Igor Mammedov <imammedo@...hat.com>,
Marc Zyngier <maz@...nel.org>,
James Morse <james.morse@....com>,
Julien Thierry <julien.thierry.kdev@...il.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Huacai Chen <chenhuacai@...nel.org>,
Aleksandar Markovic <aleksandar.qemu.devel@...il.com>,
Paul Mackerras <paulus@...abs.org>,
Christian Borntraeger <borntraeger@...ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>,
Cornelia Huck <cohuck@...hat.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>,
Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: Scalable memslots implementation
>> The new implementation also uses standard kernel {rb,interval}-tree
>> and hash table implementation as its basic data structures, so it
>> automatically benefits from any generic improvements to these.
>>
>> All for the low price of just 174 net lines of code added.
>
> I think the best thing to do here is to provide a patch series that
> splits the individual changes so that they can be reviewed and their
> separate merits evaluated.
>
> Another thing that I dislike about KVM_SET_USER_MEMORY_REGION is that
> IMO userspace should provide all memslots at once, for an atomic switch
> of the whole memory array. (Or at least I would like to see the code;
> it might be a bit tricky because you'll need code to compute the
> difference between the old and new arrays and invoke
> kvm_arch_prepare/commit_memory_region). I'm not sure how that would
> interact with the active/inactive pair that you introduce here.
>
+1
One issue I am aware of is resizing/splitting slots, especially due to
arrays like rmap + dirty bitmaps.
BTW: what are your thoughts regarding converting the rmap array on
x86-64 into some dynamic datastructre (xarray etc)? Has that already
been discussed?
> Paolo
>
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists