From: Sean Christopherson <seanjc@google.com>
To: Kenta Ishiguro <kentaishiguro@sslab.ics.keio.ac.jp>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
David Hildenbrand <david@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
pl@sslab.ics.keio.ac.jp, kono@sslab.ics.keio.ac.jp
Subject: Re: [RFC PATCH 2/2] Boost vCPUs based on IPI-sender and receiver information
Date: Wed, 21 Apr 2021 15:43:51 +0000 [thread overview]
Message-ID: <YIBIN7i7W6SuDqjN@google.com> (raw)
In-Reply-To: <20210421150831.60133-3-kentaishiguro@sslab.ics.keio.ac.jp>
On Thu, Apr 22, 2021, Kenta Ishiguro wrote:
> This commit monitors IPI communication between vCPUs and leverages the
> relationship between vCPUs to select boost candidates.
>
> Cc: David Hildenbrand <david@redhat.com>
> Signed-off-by: Kenta Ishiguro <kentaishiguro@sslab.ics.keio.ac.jp>
> ---
> arch/x86/kvm/lapic.c | 14 ++++++++++++++
> arch/x86/kvm/vmx/vmx.c | 2 ++
> include/linux/kvm_host.h | 5 +++++
> virt/kvm/kvm_main.c | 26 ++++++++++++++++++++++++--
> 4 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index cc369b9ad8f1..c8d967ddecf9 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -1269,6 +1269,18 @@ void kvm_apic_set_eoi_accelerated(struct kvm_vcpu *vcpu, int vector)
> }
> EXPORT_SYMBOL_GPL(kvm_apic_set_eoi_accelerated);
>
> +static void mark_ipi_receiver(struct kvm_lapic *apic, struct kvm_lapic_irq *irq)
> +{
> + struct kvm_vcpu *dest_vcpu;
> + u64 prev_ipi_received;
> +
> + dest_vcpu = kvm_get_vcpu_by_id(apic->vcpu->kvm, irq->dest_id);
> + if (READ_ONCE(dest_vcpu->sched_outed)) {
> + prev_ipi_received = READ_ONCE(dest_vcpu->ipi_received);
> + WRITE_ONCE(dest_vcpu->ipi_received, prev_ipi_received | (1 << apic->vcpu->vcpu_id));
The lack of "ull" on '1' actually means this will probably go sideways at >32 vCPUs.
Regardless, there needs to be an actual fallback path when the number of vCPUs
exceeds what the IPI-boost can support. That said, it should be quite easy to
allocate a bitmap to support an arbitrary number of vCPUs.
> + }
> +}
> +
> void kvm_apic_send_ipi(struct kvm_lapic *apic, u32 icr_low, u32 icr_high)
> {
> struct kvm_lapic_irq irq;
> @@ -1287,6 +1299,8 @@ void kvm_apic_send_ipi(struct kvm_lapic *apic, u32 icr_low, u32 icr_high)
>
> trace_kvm_apic_ipi(icr_low, irq.dest_id);
>
> + mark_ipi_receiver(apic, &irq);
> +
> kvm_irq_delivery_to_apic(apic->vcpu->kvm, apic, &irq, NULL);
> }
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 29b40e092d13..ced50935a38b 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6718,6 +6718,8 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
> vmcs_write32(PLE_WINDOW, vmx->ple_window);
> }
>
> + WRITE_ONCE(vcpu->ipi_received, 0);
> +
> /*
> * We did this in prepare_switch_to_guest, because it needs to
> * be within srcu_read_lock.
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 1b65e7204344..6726aeec03e7 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -320,6 +320,11 @@ struct kvm_vcpu {
> #endif
> bool preempted;
> bool ready;
> + bool sched_outed;
> + /*
> + * The current implementation of strict boost supports up to 64 vCPUs
> + */
> + u64 ipi_received;
...
> struct kvm_vcpu_arch arch;
> struct kvm_dirty_ring dirty_ring;
> };
next prev parent reply other threads:[~2021-04-21 15:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-21 15:08 [RFC PATCH 0/2] Mitigating Excessive Pause-Loop Exiting in VM-Agnostic KVM Kenta Ishiguro
2021-04-21 15:08 ` [RFC PATCH 1/2] Prevent CFS from ignoring boost requests from KVM Kenta Ishiguro
2021-04-21 18:42 ` kernel test robot
2021-04-21 15:08 ` [RFC PATCH 2/2] Boost vCPUs based on IPI-sender and receiver information Kenta Ishiguro
2021-04-21 15:43 ` Sean Christopherson [this message]
2021-04-21 16:16 ` Sean Christopherson
2021-04-21 16:19 ` [RFC PATCH 0/2] Mitigating Excessive Pause-Loop Exiting in VM-Agnostic KVM Sean Christopherson
2021-04-22 12:21 ` Wanpeng Li
2021-04-22 15:58 ` Sean Christopherson
[not found] ` <CAOOWTGJvFB_hgSUzaqNaNigdkRXFcaK37F9V7kmL3nCG+bFz5Q@mail.gmail.com>
2021-04-26 3:02 ` Wanpeng Li
2021-04-26 3:18 ` Kenta Ishiguro
2021-04-26 3:58 ` Wanpeng Li
2021-04-26 4:10 ` Kenta Ishiguro
2021-04-22 0:55 ` 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=YIBIN7i7W6SuDqjN@google.com \
--to=seanjc@google.com \
--cc=david@redhat.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kentaishiguro@sslab.ics.keio.ac.jp \
--cc=kono@sslab.ics.keio.ac.jp \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=pl@sslab.ics.keio.ac.jp \
--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.