| Message ID | 20210429211833.3361994-1-bgardon@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Lazily allocate memslot rmaps | expand |
On 29/04/21 23:18, Ben Gardon wrote: > This series enables KVM to save memory when using the TDP MMU by waiting > to allocate memslot rmaps until they are needed. To do this, KVM tracks > whether or not a shadow root has been allocated. In order to get away > with not allocating the rmaps, KVM must also be sure to skip operations > which iterate over the rmaps. If the TDP MMU is in use and we have not > allocated a shadow root, these operations would essentially be op-ops > anyway. Skipping the rmap operations has a secondary benefit of avoiding > acquiring the MMU lock in write mode in many cases, substantially > reducing MMU lock contention. > > This series was tested on an Intel Skylake machine. With the TDP MMU off > and on, this introduced no new failures on kvm-unit-tests or KVM selftests. Thanks, I only reported some technicalities in the ordering of loads (which matter since the loads happen with SRCU protection only). Apart from this, this looks fine! Paolo > Changelog: > v2: > Incorporated feedback from Paolo and Sean > Replaced the memslot_assignment_lock with slots_arch_lock, which > has a larger critical section. > > Ben Gardon (7): > KVM: x86/mmu: Track if shadow MMU active > KVM: x86/mmu: Skip rmap operations if shadow MMU inactive > KVM: x86/mmu: Deduplicate rmap freeing > KVM: x86/mmu: Factor out allocating memslot rmap > KVM: mmu: Refactor memslot copy > KVM: mmu: Add slots_arch_lock for memslot arch fields > KVM: x86/mmu: Lazily allocate memslot rmaps > > arch/x86/include/asm/kvm_host.h | 13 +++ > arch/x86/kvm/mmu/mmu.c | 153 +++++++++++++++++++++----------- > arch/x86/kvm/mmu/mmu_internal.h | 2 + > arch/x86/kvm/mmu/tdp_mmu.c | 6 +- > arch/x86/kvm/mmu/tdp_mmu.h | 4 +- > arch/x86/kvm/x86.c | 110 +++++++++++++++++++---- > include/linux/kvm_host.h | 9 ++ > virt/kvm/kvm_main.c | 54 ++++++++--- > 8 files changed, 264 insertions(+), 87 deletions(-) >
On Mon, May 3, 2021 at 6:45 AM Paolo Bonzini <pbonzini@redhat.com> wrote: > > On 29/04/21 23:18, Ben Gardon wrote: > > This series enables KVM to save memory when using the TDP MMU by waiting > > to allocate memslot rmaps until they are needed. To do this, KVM tracks > > whether or not a shadow root has been allocated. In order to get away > > with not allocating the rmaps, KVM must also be sure to skip operations > > which iterate over the rmaps. If the TDP MMU is in use and we have not > > allocated a shadow root, these operations would essentially be op-ops > > anyway. Skipping the rmap operations has a secondary benefit of avoiding > > acquiring the MMU lock in write mode in many cases, substantially > > reducing MMU lock contention. > > > > This series was tested on an Intel Skylake machine. With the TDP MMU off > > and on, this introduced no new failures on kvm-unit-tests or KVM selftests. > > Thanks, I only reported some technicalities in the ordering of loads > (which matter since the loads happen with SRCU protection only). Apart > from this, this looks fine! Awesome to hear, thank you for the reviews. Should I send a v3 addressing those comments, or did you already make those changes when applying to your tree? > > Paolo > > > Changelog: > > v2: > > Incorporated feedback from Paolo and Sean > > Replaced the memslot_assignment_lock with slots_arch_lock, which > > has a larger critical section. > > > > Ben Gardon (7): > > KVM: x86/mmu: Track if shadow MMU active > > KVM: x86/mmu: Skip rmap operations if shadow MMU inactive > > KVM: x86/mmu: Deduplicate rmap freeing > > KVM: x86/mmu: Factor out allocating memslot rmap > > KVM: mmu: Refactor memslot copy > > KVM: mmu: Add slots_arch_lock for memslot arch fields > > KVM: x86/mmu: Lazily allocate memslot rmaps > > > > arch/x86/include/asm/kvm_host.h | 13 +++ > > arch/x86/kvm/mmu/mmu.c | 153 +++++++++++++++++++++----------- > > arch/x86/kvm/mmu/mmu_internal.h | 2 + > > arch/x86/kvm/mmu/tdp_mmu.c | 6 +- > > arch/x86/kvm/mmu/tdp_mmu.h | 4 +- > > arch/x86/kvm/x86.c | 110 +++++++++++++++++++---- > > include/linux/kvm_host.h | 9 ++ > > virt/kvm/kvm_main.c | 54 ++++++++--- > > 8 files changed, 264 insertions(+), 87 deletions(-) > > >
On 03/05/21 19:31, Ben Gardon wrote: > On Mon, May 3, 2021 at 6:45 AM Paolo Bonzini <pbonzini@redhat.com> wrote: >> >> On 29/04/21 23:18, Ben Gardon wrote: >>> This series enables KVM to save memory when using the TDP MMU by waiting >>> to allocate memslot rmaps until they are needed. To do this, KVM tracks >>> whether or not a shadow root has been allocated. In order to get away >>> with not allocating the rmaps, KVM must also be sure to skip operations >>> which iterate over the rmaps. If the TDP MMU is in use and we have not >>> allocated a shadow root, these operations would essentially be op-ops >>> anyway. Skipping the rmap operations has a secondary benefit of avoiding >>> acquiring the MMU lock in write mode in many cases, substantially >>> reducing MMU lock contention. >>> >>> This series was tested on an Intel Skylake machine. With the TDP MMU off >>> and on, this introduced no new failures on kvm-unit-tests or KVM selftests. >> >> Thanks, I only reported some technicalities in the ordering of loads >> (which matter since the loads happen with SRCU protection only). Apart >> from this, this looks fine! > > Awesome to hear, thank you for the reviews. Should I send a v3 > addressing those comments, or did you already make those changes when > applying to your tree? No, I didn't (I wanted some oversight, and this is 5.14 stuff anyway). Paolo
On Tue, May 4, 2021 at 12:21 AM Paolo Bonzini <pbonzini@redhat.com> wrote: > > On 03/05/21 19:31, Ben Gardon wrote: > > On Mon, May 3, 2021 at 6:45 AM Paolo Bonzini <pbonzini@redhat.com> wrote: > >> > >> On 29/04/21 23:18, Ben Gardon wrote: > >>> This series enables KVM to save memory when using the TDP MMU by waiting > >>> to allocate memslot rmaps until they are needed. To do this, KVM tracks > >>> whether or not a shadow root has been allocated. In order to get away > >>> with not allocating the rmaps, KVM must also be sure to skip operations > >>> which iterate over the rmaps. If the TDP MMU is in use and we have not > >>> allocated a shadow root, these operations would essentially be op-ops > >>> anyway. Skipping the rmap operations has a secondary benefit of avoiding > >>> acquiring the MMU lock in write mode in many cases, substantially > >>> reducing MMU lock contention. > >>> > >>> This series was tested on an Intel Skylake machine. With the TDP MMU off > >>> and on, this introduced no new failures on kvm-unit-tests or KVM selftests. > >> > >> Thanks, I only reported some technicalities in the ordering of loads > >> (which matter since the loads happen with SRCU protection only). Apart > >> from this, this looks fine! > > > > Awesome to hear, thank you for the reviews. Should I send a v3 > > addressing those comments, or did you already make those changes when > > applying to your tree? > > No, I didn't (I wanted some oversight, and this is 5.14 stuff anyway). Ah, okay I'll send out a v3 soon, discussion on the other patches settles. > > Paolo >
On Tue, May 04, 2021, Ben Gardon wrote: > On Tue, May 4, 2021 at 12:21 AM Paolo Bonzini <pbonzini@redhat.com> wrote: > > > > On 03/05/21 19:31, Ben Gardon wrote: > > > On Mon, May 3, 2021 at 6:45 AM Paolo Bonzini <pbonzini@redhat.com> wrote: > > >> > > >> On 29/04/21 23:18, Ben Gardon wrote: > > >>> This series enables KVM to save memory when using the TDP MMU by waiting > > >>> to allocate memslot rmaps until they are needed. To do this, KVM tracks > > >>> whether or not a shadow root has been allocated. In order to get away > > >>> with not allocating the rmaps, KVM must also be sure to skip operations > > >>> which iterate over the rmaps. If the TDP MMU is in use and we have not > > >>> allocated a shadow root, these operations would essentially be op-ops > > >>> anyway. Skipping the rmap operations has a secondary benefit of avoiding > > >>> acquiring the MMU lock in write mode in many cases, substantially > > >>> reducing MMU lock contention. > > >>> > > >>> This series was tested on an Intel Skylake machine. With the TDP MMU off > > >>> and on, this introduced no new failures on kvm-unit-tests or KVM selftests. > > >> > > >> Thanks, I only reported some technicalities in the ordering of loads > > >> (which matter since the loads happen with SRCU protection only). Apart > > >> from this, this looks fine! > > > > > > Awesome to hear, thank you for the reviews. Should I send a v3 > > > addressing those comments, or did you already make those changes when > > > applying to your tree? > > > > No, I didn't (I wanted some oversight, and this is 5.14 stuff anyway). > > Ah, okay I'll send out a v3 soon, discussion on the other patches settles. I'll look through v2 this afternoon, now that I've mostly dug myself out of RDPID hell.