From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RFC v1 4/4] libxc for rt scheduler Date: Fri, 11 Jul 2014 18:35:13 +0200 Message-ID: <1405096513.29306.543.camel@Solace> References: <1405054198-29106-1-git-send-email-mengxu@cis.upenn.edu> <1405054198-29106-5-git-send-email-mengxu@cis.upenn.edu> <1405090176.29306.451.camel@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7198887219344486857==" 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: Ian Campbell , Sisu Xi , Stefano Stabellini , George Dunlap , Ian Jackson , "xen-devel@lists.xen.org" , Meng Xu , Chong Li , Dagaen Golomb List-Id: xen-devel@lists.xenproject.org --===============7198887219344486857== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4f6scsSBeDia2nnKo8s8" --=-4f6scsSBeDia2nnKo8s8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable An unrelated thing, can you set your mail client to send text message, instead of HTML ones? On ven, 2014-07-11 at 12:23 -0400, Meng Xu wrote: > My view here is, since per-VCPU scheduling parameters are > important for > this scheduler, you either: > - provide an interface for getting and setting the parameters > of _one_ > _VCPU_, and the call them repeatedly, if for instance you > need to act > on a domain. In this case, no array and no bouncing should > be > necessary. > - provide both the above, and another interface, that one > with an array > as big as the number of VCPUs of the domain, and use it to > provide > the hypervisor with the parameters of all the VCPUs, and > act > appropriately inside Xen. > =20 > Personally, I'd start with the former, and add the latter > later, if we > deem it necessary. >=20 >=20 > Actually, we did the former one in the very early version of the rt > scheduler. The only concern I have about the former version is that it > has to issue the hypercall for many times to get all VCPUs' > information of a domain, while the later one only issue the hypercall > once with bouncing.=20 >=20 True. However, if you only want to get or set one particular vcpu, it's annoying to have to deal with the array, isn't it? So, both solutions have up and down sides, depending on what you actually need. :-) This is why I was suggesting to implement both. Of course, it does not matter much which one you implement first. Se, feel free to implement the array variant properly first, and then we'll see if we also need the single VCPU variant. > My concern is: Will the former one has worse performance than the > later one? =E2=80=8B >=20 Well, Xen has its tricks, but yes, I think performing e.g., 8 or 16 hypercalls in a loop is worse than issueing one returning an array. It also must be noted that, getting and setting scheduling parameters, should not happen in very critical path, so it probably won't matter much. Anyway, as said above, go for the array first if you like it better. When you do that, consider Andrew's comments to the bottom of patch 1: "As a gut feel, I think that these two ints should be part of the struct xen_domctl_sched_rt below, with a guest handle pointing to an array of { period, budget } structures, which avoids the LEGACY_MAX limit." I don't think you'll need vcpu_index any longer, and I'm not sure whether you need max_vcpus to be part of the interface of this hcall, or if you're better out fetching it from some other call, though. Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-4f6scsSBeDia2nnKo8s8 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 iEYEABECAAYFAlPAEkEACgkQk4XaBE3IOsR96gCeKckMmefrS1PFc8bL5rwzqyDm lJ0AnAr8fEGZR3+M9Hyn88JJgMhjMFO7 =vXty -----END PGP SIGNATURE----- --=-4f6scsSBeDia2nnKo8s8-- --===============7198887219344486857== 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 --===============7198887219344486857==--