Re: Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling

From: Dario Faggioli <dario.faggioli@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Jan Beulich <jbeulich@suse.com>, Feng Wu <feng.wu@intel.com>
Subject: Re: Ideas Re: [PATCH v14 1/2] vmx: VT-d posted-interrupt core logic handling
Date: Mon, 7 Mar 2016 17:19:59 +0100	[thread overview]
Message-ID: <1457367599.3102.41.camel@citrix.com> (raw)
In-Reply-To: <20160307155304.GD5402@localhost.localdomain>

[-- Attachment #1.1: Type: text/plain, Size: 2088 bytes --]

On Mon, 2016-03-07 at 10:53 -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 07, 2016 at 11:21:33AM +0000, George Dunlap wrote:
> > 
> > > <handwaving>
> > > Would it be perhaps possible to have an anti-affinity flag to
> > > deter the
> > > scheduler from this? That is whichever struct vcpu has 'anti-
> > > affinity' flag
> > > set - the scheduler will try as much as it can _to not_ schedule
> > > the 'struct vcpu'
> > > if the previous 'struct vcpu' had this flag as well on this pCPU?
>
That can also be seen as step in the direction of (supporting) gang
scheduling, which we've said already it would be something interesting
to look at, although difficult to implement and even more difficult to
figure out whether it is actually a good thing for most workloads.

In any case, I see from where this comes, and am up for thinking about
it, although my fear is that it would complicate the code by quite a
bit, so I agree with George that profiling work is necessary to try to
assess whether it could be really useful (as well as, once
implemented/drafted, whether it is really good and does not cause perf
regressions).

> > On the whole it seems unlikely that having two vcpus on a single
> > pcpu
> > is a "stable" situation -- it's likely to be pretty transient, and
> > thus not have a major impact on performance.
> Except that we are concerned with it - in fact we are disabling this
> feature because it may happen. 
>
I'm sorry, I'm not getting, what feature are you disabling?

> > But I think some profiling is in order before anyone does serious
> > work on this.
> I appreciate your response being 'profiling' instead of 'Are you
> NUTS!?' :-)
> 
That's only because everyone knows you're nuts, there's no need to
state it all the times! :-P :-P

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel