mbox series

[v2,0/6] kvm->lock vs. SRCU sync optimizations

Message ID 20230107001256.2365304-1-mhal@rbox.co (mailing list archive)
Headers show
Series kvm->lock vs. SRCU sync optimizations | expand

Message

Michal Luczaj Jan. 7, 2023, 12:12 a.m. UTC
This series is mostly about unlocking kvm->lock before synchronizing SRCU.
Discussed at https://lore.kernel.org/kvm/Y7dN0Negds7XUbvI@google.com/ .

I'm mentioning the fact it's an optimization (not a bugfix; at least under
the assumption that Xen does not break the lock order anymore) meant to
reduce the time spent under the mutex. Sean, would that suffice?

Along the way simplification and cleanups are smuggled.

And, by the way, what about other sync-under-lock cases such as

kvm_arch_vm_ioctl KVM_CREATE_PIT
  mutex_lock(&kvm->lock)
  kvm_create_pit()
    kvm_io_bus_register_dev()
      synchronize_srcu_expedited(&kvm->srcu)

Does this qualify for some form of refactoring?

Michal Luczaj (6):
  KVM: x86: Optimize kvm->lock and SRCU interaction
    (KVM_SET_PMU_EVENT_FILTER)
  KVM: x86: Optimize kvm->lock and SRCU interaction
    (KVM_X86_SET_MSR_FILTER)
  KVM: x86: Simplify msr_filter update
  KVM: x86: Explicitly state lockdep condition of msr_filter update
  KVM: x86: Remove unnecessary initialization in
    kvm_vm_ioctl_set_msr_filter()
  KVM: x86: Simplify msr_io()

 arch/x86/kvm/pmu.c |  3 +--
 arch/x86/kvm/x86.c | 22 +++++++---------------
 2 files changed, 8 insertions(+), 17 deletions(-)

Comments

Sean Christopherson Feb. 4, 2023, 12:31 a.m. UTC | #1
On Sat, 07 Jan 2023 01:12:50 +0100, Michal Luczaj wrote:
> This series is mostly about unlocking kvm->lock before synchronizing SRCU.
> Discussed at https://lore.kernel.org/kvm/Y7dN0Negds7XUbvI@google.com/ .
> 
> I'm mentioning the fact it's an optimization (not a bugfix; at least under
> the assumption that Xen does not break the lock order anymore) meant to
> reduce the time spent under the mutex. Sean, would that suffice?
> 
> [...]

Applied to kvm-x86 misc, thanks!

Note, I massaged a few changelogs to provide more context and justification,
but didn't see a need to respond to individual patches.

[1/6] KVM: x86: Optimize kvm->lock and SRCU interaction (KVM_SET_PMU_EVENT_FILTER)
      https://github.com/kvm-x86/linux/commit/95744a90db18
[2/6] KVM: x86: Optimize kvm->lock and SRCU interaction (KVM_X86_SET_MSR_FILTER)
      https://github.com/kvm-x86/linux/commit/708f799d22fe
[3/6] KVM: x86: Simplify msr_filter update
      https://github.com/kvm-x86/linux/commit/4d85cfcaa82f
[4/6] KVM: x86: Explicitly state lockdep condition of msr_filter update
      https://github.com/kvm-x86/linux/commit/1fdefb8bd862
[5/6] KVM: x86: Remove unnecessary initialization in kvm_vm_ioctl_set_msr_filter()
      https://github.com/kvm-x86/linux/commit/4559e6cf45b5
[6/6] KVM: x86: Simplify msr_io()
      https://github.com/kvm-x86/linux/commit/e73ba25fdc24

--
https://github.com/kvm-x86/linux/tree/next
https://github.com/kvm-x86/linux/tree/fixes
Michal Luczaj Feb. 4, 2023, 12:44 p.m. UTC | #2
On 2/4/23 01:31, Sean Christopherson wrote:
> On Sat, 07 Jan 2023 01:12:50 +0100, Michal Luczaj wrote:
>> This series is mostly about unlocking kvm->lock before synchronizing SRCU.
>> Discussed at https://lore.kernel.org/kvm/Y7dN0Negds7XUbvI@google.com/ .
>>
>> I'm mentioning the fact it's an optimization (not a bugfix; at least under
>> the assumption that Xen does not break the lock order anymore) meant to
>> reduce the time spent under the mutex. Sean, would that suffice?
>>
>> [...]
> 
> Applied to kvm-x86 misc, thanks!
> 
> Note, I massaged a few changelogs to provide more context and justification,
> but didn't see a need to respond to individual patches.

Sure, thanks.

Michal