From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v2 for Xen 4.6 3/4] libxl: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler Date: Tue, 9 Jun 2015 18:18:58 +0200 Message-ID: <1433866738.2403.181.camel@citrix.com> References: <1432598984-20914-1-git-send-email-chong.li@wustl.edu> <1433504253.7108.231.camel@citrix.com> <1433778984.2403.27.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6463564584237032268==" 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: Chong Li Cc: Chong Li , Wei Liu , Ian Campbell , Sisu Xi , George Dunlap , Ian Jackson , xen-devel , Meng Xu , Dagaen Golomb List-Id: xen-devel@lists.xenproject.org --===============6463564584237032268== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-q1PP4nv9V9mqTlM8ZmgO" --=-q1PP4nv9V9mqTlM8ZmgO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-06-08 at 15:55 -0500, Chong Li wrote: > On Mon, Jun 8, 2015 at 10:56 AM, Dario Faggioli > > So, Thoughts? What do you think the best way forward could be? >=20 > I like option 2 more. But I think we may also need a 'vcpuid' field in > libxl_sched_params. >=20 For sparse array support, yes. At which point, I would flip the names as well, i.e., something like this: libxl_vcpu_sched_params =3D Struct("vcpu_sched_params",[ ("vcpuid", integer, { xxx some init val xxx}), ("weight", integer, {'init_val': 'LIBXL_PARAM_WEIGHT_DEFAULT'}), ("cap", integer, {'init_val': 'LIBXL_PARAM_CAP_DEFAULT'}), ("period", integer, {'init_val': 'LIBXL_PARAM_PERIOD_DEFAULT'}), ("slice", integer, {'init_val': 'LIBXL_PARAM_SLICE_DEFAULT'}), ("latency", integer, {'init_val': 'LIBXL_PARAM_LATENCY_DEFAULT'}), ("extratime", integer, {'init_val': 'LIBXL_PARAM_EXTRATIME_DEFAULT'}= ), ("budget", integer, {'init_val': 'LIBXL_PARAM_BUDGET_DEFAULT'}), ]) libxl_sched_params =3D Struct("sched_params",[ ("sched", libxl_scheduler), ("vcpus", Array(libxl_sched_params, "num_vcpus")), ]) With the possibility of naming the latter 'libxl_vcpus_sched_params', which is more descriptive, but perhaps is too similar to libxl_vcpu_sched_params. Ian, George, what do you think? While we're here, another thing we would appreciate some feedback on is what should happen to libxl_domain_sched_params_get(). This occurred to my mind while reviewing patch 4 of this series. Actually, I think we've discussed this before, but can't find the reference now. Anyway, my view is that, for a scheduler that uses per-vcpu parameters, libxl_domain_sched_params_set() should set the same parameters for all the vcpus. When it comes to _get(), however, I'm not sure. To match the _set() case, we'd need to return the parameters of all the vcpus, but we can't, because the function takes a libxl_domain_sched_params argument, which just holds 1 tuple. Should we just WARN and ask, when on that specific scheduler, to use the per-vcpu variant being introduced in this patch (libxl_vcpu_sched_params_get())? This does not look ideal, but without changing the prototype of libxl_domain_sched_params_get(), I don't see what else sensible we could do... :-/ Should we change it, and do the LIBXL_API_VERSION "trick"? So, again, thoughts? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-q1PP4nv9V9mqTlM8ZmgO 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 iEYEABECAAYFAlV3EfMACgkQk4XaBE3IOsR3ggCfZUS/UuPC5YjTKSrUQO2N7Bla SmEAnR5XBbAYS9YteupVbksGpcpfugEZ =cP3I -----END PGP SIGNATURE----- --=-q1PP4nv9V9mqTlM8ZmgO-- --===============6463564584237032268== 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 --===============6463564584237032268==--