From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Wu, Feng" <feng.wu@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts
Date: Wed, 25 Nov 2015 16:43:09 +0100 [thread overview]
Message-ID: <20151125154308.GD13925@potion.brq.redhat.com> (raw)
In-Reply-To: <5655C7C9.1010008@redhat.com>
2015-11-25 15:38+0100, Paolo Bonzini:
> On 25/11/2015 15:12, Radim Krcmár wrote:
>> I think it's ok to pick any algorithm we like. It's unlikely that
>> software would recognize and take advantage of the hardware algorithm
>> without adding a special treatment for KVM.
>> (I'd vote for the simple pick-first-APIC lowest priority algorithm ...
>> I don't see much point in complicating lowest priority when it doesn't
>> deliver to lowest priority CPU anyway.)
>
> Vector hashing is an improvement for the common case where all vectors
> are set to all CPUs. Sure you can get an unlucky assignment, but it's
> still better than pick-first-APIC.
Yeah, hashing has a valid use case, but a subtle weighting of drawbacks
led me to prefer pick-first-APIC ...
(I'd prefer to have simple code in KVM and depend on static IRQ balancing
in a guest to handle the distribution.
The guest could get the unlucky assignment anyway, so it should be
prepared; and hashing just made KVM worse in that case. Guests might
also configure physical x(2)APIC, where is no lowest priority.
And if the guest doesn't do anything with IRQs, then it might not even
care about the impact that our choice has.)
next prev parent reply other threads:[~2015-11-25 15:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-09 2:46 [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts Feng Wu
2015-11-16 6:18 ` Wu, Feng
2015-11-16 19:03 ` Radim Krčmář
2015-11-17 9:41 ` Paolo Bonzini
2015-11-24 1:26 ` Wu, Feng
2015-11-24 14:35 ` Radim Krcmár
2015-11-24 14:38 ` Paolo Bonzini
2015-11-25 1:58 ` Wu, Feng
2015-11-25 11:32 ` Paolo Bonzini
2015-11-24 1:26 ` Wu, Feng
2015-11-24 14:31 ` Radim Krčmář
2015-11-24 14:44 ` Radim Krčmář
2015-11-25 3:21 ` Wu, Feng
2015-11-25 14:12 ` Radim Krcmár
2015-11-25 14:38 ` Paolo Bonzini
2015-11-25 15:43 ` Radim Krčmář [this message]
2015-11-26 6:24 ` Wu, Feng
2015-11-26 14:03 ` Radim Krcmár
2015-12-09 8:19 ` Wu, Feng
2015-12-09 14:53 ` Radim Krčmář
2015-12-10 1:52 ` Wu, Feng
2015-12-11 14:37 ` Radim Krcmár
2015-12-15 1:52 ` Wu, Feng
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=20151125154308.GD13925@potion.brq.redhat.com \
--to=rkrcmar@redhat.com \
--cc=feng.wu@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox