From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v2] Modified RTDS scheduler to use an event-driven model instead of polling. Date: Fri, 10 Jul 2015 12:07:22 +0200 Message-ID: <1436522842.22672.357.camel@citrix.com> References: <1435434410-15776-1-git-send-email-dgolomb@seas.upenn.edu> <1436203828.10763.39.camel@citrix.com> <1436277826.22672.94.camel@citrix.com> <1436342472.22672.175.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2000036659378207956==" 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: Meng Xu Cc: Sisu Xi , George Dunlap , "xen-devel@lists.xen.org" , "mengxu@cis.upenn.edu" , Chong Li , Dagaen Golomb List-Id: xen-devel@lists.xenproject.org --===============2000036659378207956== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-qwqK2Y/03UdqEfycdn9/" --=-qwqK2Y/03UdqEfycdn9/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-07-08 at 20:46 -0700, Meng Xu wrote: > 2015-07-08 1:01 GMT-07:00 Dario Faggioli : > But after thinking twice, maybe runq approach is a better way since it > just make the position information more meaningful. As you described > in the previous email, we can compare the position of a vcpu inserted > into the runq with the number of pCPUs so as to quickly know which > pCPU to tickle. >=20 > > I appreciate this is a rather big change > > (although, perhaps it looks bigger said than done), but I think it coul= d > > be worth pursuing. >=20 > It is worth pursuing since it simplify the cpu tickling process a lot. >=20 Great! :-) > > I think that I'd like to know why you think adding another queue is > > necessary, instead of just leaving the vCPUs in the actual runq. Is > > there something bad about that which I'm missing? >=20 > Actually, nothing bad. I just recalled the situation when we split a > runq to runq and delpetedq. I was thinking it might be the case here > as well. (Yes, it is different here since we can get more useful > information to tickle cpu if we put vCPUs into runq instead of adding > one more queue.) :-) > > IMO, having things split could be beneficial for scalability *BUT* only in case we also get rid of the big spin lock. Until we won't get there (which is not that urgent) using the same queue is fine. For runq and depletedq, the same applies, with the small difference that, since both need to be sorted, having two actual queues looks easier than having just one with a marker, but that's only an implementation detail, it's fine however it is. OTOH, in this case, using runq only, without introducing another queue, actually helps making things simpler! > > Yes, but if we use two queues, we defeat at least part of this > > optimization/simplification. >=20 > Agree. Thanks! :-D >=20 Perfect. Looking also at Dagaen replies, it sounds like we have a plan! Looking forward to see the code! :-D > > I don't think the added space would be a problem, but I don't see why w= e > > need it. >=20 > If we don't add another queue, no extra space. So we get free lunch here.= :-) >=20 Yeah, but let's not exaggerate with free lunches, I'm trying to loose some weight! :-P Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-qwqK2Y/03UdqEfycdn9/ 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 iEYEABECAAYFAlWfmWIACgkQk4XaBE3IOsTq2QCdGdhqwQATzssIlDo0OPT10fzq BckAoKyvq5TQ3mEpiyGNDEtrdCgDbO7A =r3Ns -----END PGP SIGNATURE----- --=-qwqK2Y/03UdqEfycdn9/-- --===============2000036659378207956== 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 --===============2000036659378207956==--