[lkml]   [2017]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH RFC 0/2] KVM: use RCU to allow dynamic kvm->vcpus array
On 16.08.2017 21:40, Radim Krčmář wrote:
> The goal is to increase KVM_MAX_VCPUS without worrying about memory
> impact of many small guests.
> This is a second out of three major "dynamic" options:
> 1) size vcpu array at VM creation time
> 2) resize vcpu array when new VCPUs are created
> 3) use a lockless list/tree for VCPUs
> The disadvantage of (1) is its requirement on userspace changes and
> limited flexibility because userspace must provide the maximal count on
> start. The main advantage is that kvm->vcpus will work like it does
> now. It has been posted as "[PATCH 0/4] KVM: add KVM_CREATE_VM2 to
> allow dynamic kvm->vcpus array",
> The main problem of (2), this series, is that we cannot extend the array
> in place and therefore require some kind of protection when moving it.
> RCU seems best, but it makes the code slower and harder to deal with.
> The main advantage is that we do not need userspace changes.
> The third option wasn't explored yet. It would solve the ugly
> kvm_for_each_vcpu() of (2), but kvm_get_vcpu() would become linear.
> (We could mitigate it by having list of vcpu arrays and A lockless
> sequentially growing "tree" would be logarithmic and not that much more
> complicated to implement.)

That sounds interesting but also too complicated.

> Which option do you think is the best?

I actually think the RCU variant doesn't look bad at all. Execution time
should be ok.

As Alex said, doubling the size every time we run out of space could be

I clearly favor a solution that doesn't require user space changes.




 \ /
  Last update: 2017-08-17 09:31    [W:0.109 / U:0.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site