[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <442859af-6454-b15e-b2ad-0fc7c4e22909@redhat.com>
Date: Wed, 2 Mar 2022 21:14:25 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Christian Borntraeger <borntraeger@...ux.ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>,
David Hildenbrand <david@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, David Matlack <dmatlack@...gle.com>,
Ben Gardon <bgardon@...gle.com>,
Mingwei Zhang <mizhang@...gle.com>
Subject: Re: [PATCH v3 22/28] KVM: x86/mmu: Zap defunct roots via asynchronous
worker
On 3/2/22 20:33, Sean Christopherson wrote:
> What about that idea? Put roots invalidated by "fast zap" on_another_ list?
> My very original idea of moving the roots to a separate list didn't work because
> the roots needed to be reachable by the mmu_notifier. But we could just add
> another list_head (inside the unsync_child_bitmap union) and add the roots to
> _that_ list.
Perhaps the "separate list" idea could be extended to have a single
worker for all kvm_tdp_mmu_put_root() work, and then indeed replace
kvm_tdp_mmu_zap_invalidated_roots() with a flush of _that_ worker. The
disadvantage is a little less parallelism in zapping invalidated roots;
but what is good for kvm_tdp_mmu_zap_invalidated_roots() is just as good
for kvm_tdp_mmu_put_root(), I suppose. If one wants separate work
items, KVM could have its own workqueue, and then you flush that workqueue.
For now let's do it the simple but ugly way. Keeping
next_invalidated_root() does not make things worse than the status quo,
and further work will be easier to review if it's kept separate from
this already-complex work.
Paolo
Powered by blists - more mailing lists