From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli 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 Message-ID: <1457367599.3102.41.camel@citrix.com> References: <1456714816-3876-1-git-send-email-feng.wu@intel.com> <1456714816-3876-2-git-send-email-feng.wu@intel.com> <20160304220031.GA28111@char.us.oracle.com> <20160307155304.GD5402@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5778842449725893104==" Return-path: In-Reply-To: <20160307155304.GD5402@localhost.localdomain> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Konrad Rzeszutek Wilk , George Dunlap Cc: Kevin Tian , Keir Fraser , Andrew Cooper , "xen-devel@lists.xen.org" , Jan Beulich , Feng Wu List-Id: xen-devel@lists.xenproject.org --===============5778842449725893104== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-nv8hGdHIiUpB09mZDxRW" --=-nv8hGdHIiUpB09mZDxRW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: > >=C2=A0 > > > > > > 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.=20 > 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!?' :-) >=20 That's only because everyone knows you're nuts, there's no need to state it all the times! :-P :-P Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-nv8hGdHIiUpB09mZDxRW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlbdqi8ACgkQk4XaBE3IOsSIvQCbBlS6VKORangeVyfNyU42i3ii Y1AAn0e19AmW/oL4vrI323EaAfWWLynx =iSwp -----END PGP SIGNATURE----- --=-nv8hGdHIiUpB09mZDxRW-- --===============5778842449725893104== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============5778842449725893104==--