Re: [PATCH v4 00/19] KVM: Dynamically size memslot arrays
On 2019-12-17 20:40, Sean Christopherson wrote: The end goal of this series is to dynamically size the memslot array so that KVM allocates memory based on the number of memslots in use, as opposed to unconditionally allocating memory for the maximum number of memslots. On x86, each memslot consumes 88 bytes, and so with 2 address spaces of 512 memslots, each VM consumes ~90k bytes for the memslots. E.g. given a VM that uses a total of 30 memslots, dynamic sizing reduces the memory footprint from 90k to ~2.6k bytes. The changes required to support dynamic sizing are relatively small, e.g. are essentially contained in patches 17/19 and 18/19. Patches 2-16 clean up the memslot code, which has gotten quite crusty, especially __kvm_set_memory_region(). The clean up is likely not strictly necessary to switch to dynamic sizing, but I didn't have a remotely reasonable level of confidence in the correctness of the dynamic sizing without first doing the clean up. The only functional change in v4 is the addition of an x86-specific bug fix in x86's handling of KVM_MR_MOVE. The bug fix is not directly related to dynamically allocating memslots, but it has subtle and hidden conflicts with the cleanup patches, and the fix is higher priority than anything else in the series, i.e. should be merged first. On non-x86 architectures, v3 and v4 should be functionally equivalent, the only non-x86 change in v4 is the dropping of a "const" in kvm_arch_commit_memory_region(). Gave it another go on top of 5.5-rc2 on an arm64 box, and nothing exploded. So thumbs up from me. Thanks, M. -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v4 00/19] KVM: Dynamically size memslot arrays
On 17.12.19 21:40, Sean Christopherson wrote: > The end goal of this series is to dynamically size the memslot array so > that KVM allocates memory based on the number of memslots in use, as > opposed to unconditionally allocating memory for the maximum number of > memslots. On x86, each memslot consumes 88 bytes, and so with 2 address > spaces of 512 memslots, each VM consumes ~90k bytes for the memslots. > E.g. given a VM that uses a total of 30 memslots, dynamic sizing reduces > the memory footprint from 90k to ~2.6k bytes. > > The changes required to support dynamic sizing are relatively small, > e.g. are essentially contained in patches 17/19 and 18/19. > > Patches 2-16 clean up the memslot code, which has gotten quite crusty, > especially __kvm_set_memory_region(). The clean up is likely not strictly > necessary to switch to dynamic sizing, but I didn't have a remotely > reasonable level of confidence in the correctness of the dynamic sizing > without first doing the clean up. > > The only functional change in v4 is the addition of an x86-specific bug > fix in x86's handling of KVM_MR_MOVE. The bug fix is not directly related > to dynamically allocating memslots, but it has subtle and hidden conflicts > with the cleanup patches, and the fix is higher priority than anything > else in the series, i.e. should be merged first. > > On non-x86 architectures, v3 and v4 should be functionally equivalent, > the only non-x86 change in v4 is the dropping of a "const" in > kvm_arch_commit_memory_region(). I gave this series a quick spin and it still seems to work on s390 (minus the selftest). ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
