From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [v4 16/17] vmx: Add some scheduler hooks for VT-d posted interrupts Date: Mon, 3 Aug 2015 12:02:02 +0200 Message-ID: <1438596122.16912.145.camel@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0690255856426747489==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Wu, Feng" Cc: "Tian, Kevin" , Keir Fraser , George Dunlap , Andrew Cooper , "xen-devel@lists.xen.org" , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============0690255856426747489== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jzKd461L1RYeJOUou/ju" --=-jzKd461L1RYeJOUou/ju Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-08-03 at 01:36 +0000, Wu, Feng wrote: > > -----Original Message----- > > From: Dario Faggioli [mailto:dario.faggioli@citrix.com] > > It's safe in any case. In fact, the spinlock will prevent both the > > vcpu's processor to schedule, as well as any other processors to steal > > the waking vcpu from the runqueue to run it. >=20 > Good to know this. For " as well as any other processors to steal > the waking vcpu from the runqueue to run it ", could you please show > some hints in the code side, so I can better understand how this can > be protected by the spinlock. Thank you! >=20 Sure. For instance, for the Credit1 scheduler, look at csched_load_balance(). vcpus are moved from one runqueue to another by means of csched_runq_steal() which, as you can see, is called only if the spinlock for the pcpu from where we want to try stealing has been successfully acquired: spinlock_t *lock =3D pcpu_schedule_trylock(peer_cpu); if ( !lock ) { SCHED_STAT_CRANK(steal_trylock_failed); peer_cpu =3D cpumask_cycle(peer_cpu, &workers); continue; } /* Any work over there to steal? */ speer =3D cpumask_test_cpu(peer_cpu, online) ? csched_runq_steal(peer_cpu, cpu, snext->pri, bstep) : NULL; pcpu_schedule_unlock(lock, peer_cpu); Same happen in Credit2. Check choose_cpu(), and you'll fine similar reasoning and code. In RTDS, finally, there's just one runqueue, for all pcpus, so each time each one of them has to schedule it has to take the only one spinlock protecting it. Hope this helped. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-jzKd461L1RYeJOUou/ju 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 iEYEABECAAYFAlW/PBoACgkQk4XaBE3IOsT02QCdHwjkpEXk88k9HtMzCH/Ip0/H Ob4AoIR3UHAPLWmMvFa0mKoiA8+SnhIZ =sVwi -----END PGP SIGNATURE----- --=-jzKd461L1RYeJOUou/ju-- --===============0690255856426747489== 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 --===============0690255856426747489==--