From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v7 15/17] vmx: VT-d posted-interrupt core logic handling Date: Fri, 18 Sep 2015 11:22:45 +0200 Message-ID: <1442568165.2691.17.camel@citrix.com> References: <1441960146-10569-1-git-send-email-feng.wu@intel.com> <1441960146-10569-16-git-send-email-feng.wu@intel.com> <1442423887.15327.29.camel@citrix.com> <1442479704.15327.65.camel@citrix.com> <55FA8A02.30705@citrix.com> <55FAA7AC.3010909@citrix.com> <1442493604.15327.80.camel@citrix.com> <55FACE83.6050607@citrix.com> <55FBBCD502000078000D8FE0@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5311051079720871671==" Return-path: In-Reply-To: <55FBBCD502000078000D8FE0@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , george.dunlap@citrix.com Cc: kevin.tian@intel.com, keir@xen.org, george.dunlap@eu.citrix.com, andrew.cooper3@citrix.com, xen-devel@lists.xen.org, feng.wu@intel.com List-Id: xen-devel@lists.xenproject.org --===============5311051079720871671== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VF35gwxC2cOMq5l9tgON" --=-VF35gwxC2cOMq5l9tgON Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2015-09-18 at 00:27 -0600, Jan Beulich wrote: > > George Dunlap 09/17/15 4:30 PM >>>The > > > > vcpu_block() > >set(_VPF_blocked) > >v->arch.block() > >- Add v to pcpu.pi_blocked_vcpu > >- NV =3D> pi_wakeup_vector > >local_events_need_delivery() > >hvm_vcpu_has_pending_irq() > >=20 > >... > >context_switch(): nothing > >=20 > > The other is to do the "blocking" stuff in the context switch > > (similar > > to what's done now): > >=20 > > vcpu_block() > >set(_VPF_blocked) > >local_events_need_delivery() > >hvm_vcpu_has_pending_irq() > >... > > context_switch > >v->arch.block() > >- Add v to pcpu.pi_blocked_vcpu > >- NV =3D> pi_wakeup_vector > > > > [...] > > > > > > thing I like about the first one is that it makes PI blocking > > > > the > > same as normal blocking -- everything happens in the same place; so > > the > > code is cleaner and easier to understand. > >=20 > > The thing I like about the second one is that it cleverly avoids > > having > > to do all the work of adding the vcpu to the list and then > > searching to > > remove it if the vcpu in question gets woken up on the way to being > > blocked. So the code may end up being faster for workloads where > > that > > happens frequently. >=20 > But wouldn't such an optimization argument apply to some/all other > blocking ways too? I.e. shouldn't, if we were to go that route, other > early wakeups get treated equally?=20 > Good point, actually. However, with "regular blockings" this would probably be less of an optimization. In fact, in PI case, George's solution 2 is, potentially, avoiding having to switch the descriptor and manipulating the list of blocked vcpus. In regular blockings there are no such things. We may be able to avoid a context switch, but that also depends, AFAICT, on when the interrupt exactly happens and/or is notified (i.e., before the call to schedule() as opposed to after that and before the actual __context_switch()). I'm not saying this wouldn't be better, but it's certainly optimizing less than in the PI case. > Unless that's wrong thinking of mine > or being implemented that way, I'd clearly favor option 1 for > consistency > reasons. >=20 As said, me too. Perhaps we can go for option 1, which is simpler, cleaner and more consistent, considering the current status of the code. We can always investigate, in future, whether and how to implement the optimization for all the blockings, if beneficial and fea sible, or have them diverge, if deemed worthwhile. Regards, Dario -- <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-VF35gwxC2cOMq5l9tgON 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 v1 iEYEABECAAYFAlX71+YACgkQk4XaBE3IOsS8NwCfawD3/2rN4CPIuKwwSt+abRx0 w1wAn1y16LhzVLaPWN5u+RAH0nO1lFlM =SC/e -----END PGP SIGNATURE----- --=-VF35gwxC2cOMq5l9tgON-- --===============5311051079720871671== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5311051079720871671==--