From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RFC v1 3/4] libxl for rt scheduler Date: Fri, 11 Jul 2014 17:08:49 +0200 Message-ID: <1405091329.29306.464.camel@Solace> References: <1405054198-29106-1-git-send-email-mengxu@cis.upenn.edu> <1405054198-29106-4-git-send-email-mengxu@cis.upenn.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3452795096473287226==" Return-path: In-Reply-To: <1405054198-29106-4-git-send-email-mengxu@cis.upenn.edu> 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@citrix.com, xisisu@gmail.com, stefano.stabellini@eu.citrix.com, george.dunlap@eu.citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, xumengpanda@gmail.com, lichong659@gmail.com, dgolomb@seas.upenn.edu List-Id: xen-devel@lists.xenproject.org --===============3452795096473287226== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Mew38tYO12uW4y7e0zQ9" --=-Mew38tYO12uW4y7e0zQ9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On ven, 2014-07-11 at 00:49 -0400, Meng Xu wrote: > --- a/tools/libxl/libxl.c > +++ b/tools/libxl/libxl.c > +static int sched_rt_domain_get(libxl__gc *gc, uint32_t domid, > + libxl_domain_sched_params *scinfo) > +{ > + struct xen_domctl_sched_rt_params sdom; > + int rc, i; > + > + rc =3D xc_sched_rt_domain_get(CTX->xch, domid, &sdom); > + if (rc !=3D 0) { > + LOGE(ERROR, "getting domain sched rt"); > + return ERROR_FAIL; > + } > + > + libxl_domain_sched_params_init(scinfo); > + scinfo->sched =3D LIBXL_SCHEDULER_RT; > + scinfo->rt.max_vcpus =3D LIBXL_XEN_LEGACY_MAX_VCPUS; > + /*TODO: alloc array with exact num of dom's vcpus; and use GCNEW_ARR= AY()*/ > Indeed. That, or just do an hypercall for each VCPU, at least as a first step. > + scinfo->rt.vcpus =3D (libxl_vcpu *) > + malloc( sizeof(libxl_vcpu) * scinfo->rt.max_vcpus ); > Yes, you said it yourself, I see: GCNEW_ARRAY() and no malloc() in libxl. > + if ( !scinfo->rt.vcpus ){ > + LOGE(ERROR, "Allocate lib_vcpu array fails\n"); > + return ERROR_INVAL; > + } > + scinfo->rt.num_vcpus =3D sdom.num_vcpus; > + for( i =3D 0; i < sdom.num_vcpus; ++i) > + { > + scinfo->rt.vcpus[i].period =3D sdom.vcpus[i].period; > + scinfo->rt.vcpus[i].budget =3D sdom.vcpus[i].budget; > + } > + > + return 0; > +} > + > +#define SCHED_RT_VCPU_PARAMS_MAX 4294967295 /* 2^32-1 */ > + I don't like the name. I'd go for something like SCHED_RT_VCPU_PERIOD_MAX and SCHED_RT_VCPU_BUDGET_MAX. You well can define both to the same value, of course. As per the value, yes, even if we turn the interface in usecs, 2^32 usecs is still ~4000 secs, which ought to be enough as a period or budget for everyone! :-) For the rest of this file, I think I'll wait for v2, as the interface is subject to be changed. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Mew38tYO12uW4y7e0zQ9 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 iEYEABECAAYFAlO//gEACgkQk4XaBE3IOsQm+gCdFeRn0FmRJQo+Rlw7XDZQ4rIk f2MAn2dT77voNbEgNJvqL7swC/43fY2N =SjvJ -----END PGP SIGNATURE----- --=-Mew38tYO12uW4y7e0zQ9-- --===============3452795096473287226== 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 --===============3452795096473287226==--