Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752048AbbKZGZA (ORCPT ); Thu, 26 Nov 2015 01:25:00 -0500 Received: from mga02.intel.com ([134.134.136.20]:53378 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751224AbbKZGY4 (ORCPT ); Thu, 26 Nov 2015 01:24:56 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,346,1444719600"; d="scan'208";a="694672142" From: "Wu, Feng" To: =?utf-8?B?UmFkaW0gS3JjbcOhcg==?= , Paolo Bonzini CC: "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Wu, Feng" Subject: RE: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts Thread-Topic: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted-interrupts Thread-Index: AQHRIKFx7uN6i1xR7ke/FgyVZroC0p6qX1YggABjBoCAAVqyEIAAMkGAgAAHFoCAABIzgIABevQA Date: Thu, 26 Nov 2015 06:24:52 +0000 Message-ID: References: <1447037208-75615-1-git-send-email-feng.wu@intel.com> <20151116190314.GA12245@potion.brq.redhat.com> <20151124143154.GB13925@potion.brq.redhat.com> <20151125141238.GC13925@potion.brq.redhat.com> <5655C7C9.1010008@redhat.com> <20151125154308.GD13925@potion.brq.redhat.com> In-Reply-To: <20151125154308.GD13925@potion.brq.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tAQ6P9uB001571 Content-Length: 2052 Lines: 46 > -----Original Message----- > From: Radim Krčmář [mailto:rkrcmar@redhat.com] > Sent: Wednesday, November 25, 2015 11:43 PM > To: Paolo Bonzini > Cc: Wu, Feng ; kvm@vger.kernel.org; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH] KVM: x86: Add lowest-priority support for vt-d posted- > interrupts > > 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 ... Is it possible that pick-first-APIC policy make certain vCPU's irq workload too heavy? > > (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.) Do do you guys have an agreement on how to handle this? Or we can implement the vector hashing at the current stage. then we can improve it like Radim mentioned above if it is really needed? Thanks, Feng ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?