From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <seanjc@google.com>,
Wanpeng Li <kernellwp@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, kvm <kvm@vger.kernel.org>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>
Subject: Re: [PATCH] KVM: Boost vCPU candidiate in user mode which is delivering interrupt
Date: Mon, 19 Apr 2021 18:59:13 +0200 [thread overview]
Message-ID: <c1909fa3-61f3-de6b-1aa1-8bc36285e1e4@redhat.com> (raw)
In-Reply-To: <YH2wnl05UBqVhcHr@google.com>
On 19/04/21 18:32, Sean Christopherson wrote:
> If false positives are a big concern, what about adding another pass to the loop
> and only yielding to usermode vCPUs with interrupts in the second full pass?
> I.e. give vCPUs that are already in kernel mode priority, and only yield to
> handle an interrupt if there are no vCPUs in kernel mode.
>
> kvm_arch_dy_runnable() pulls in pv_unhalted, which seems like a good thing.
pv_unhalted won't help if you're waiting for a kernel spinlock though,
would it? Doing two passes (or looking for a "best" candidate that
prefers kernel mode vCPUs to user mode vCPUs waiting for an interrupt)
seems like the best choice overall.
Paolo
next prev parent reply other threads:[~2021-04-19 16:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-16 3:08 [PATCH] KVM: Boost vCPU candidiate in user mode which is delivering interrupt Wanpeng Li
2021-04-17 13:09 ` Paolo Bonzini
2021-04-19 7:34 ` Wanpeng Li
2021-04-19 16:32 ` Sean Christopherson
2021-04-19 16:59 ` Paolo Bonzini [this message]
2021-04-20 6:02 ` Wanpeng Li
2021-04-20 6:08 ` Wanpeng Li
2021-04-20 7:22 ` Paolo Bonzini
2021-04-20 8:48 ` Wanpeng Li
2021-04-20 10:23 ` Paolo Bonzini
2021-04-20 10:27 ` Wanpeng Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c1909fa3-61f3-de6b-1aa1-8bc36285e1e4@redhat.com \
--to=pbonzini@redhat.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kernellwp@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seanjc@google.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.