From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RFC v1 3/3] xl: enable per-VCPU work conserving flag for RTDS Date: Fri, 4 Aug 2017 11:01:12 +0200 Message-ID: <1501837272.28477.17.camel@citrix.com> References: <1501612434-5803-1-git-send-email-mengxu@cis.upenn.edu> <1501612434-5803-4-git-send-email-mengxu@cis.upenn.edu> <1501776218.28477.12.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7350400818548518016==" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddYUC-0006VP-MW for xen-devel@lists.xenproject.org; Fri, 04 Aug 2017 09:01:36 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Meng Xu Cc: George Dunlap , "xen-devel@lists.xenproject.org" , Ian Jackson , Wei Liu List-Id: xen-devel@lists.xenproject.org --===============7350400818548518016== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-aUmFLxNz01YDHcUleZIW" --=-aUmFLxNz01YDHcUleZIW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2017-08-03 at 18:02 -0400, Meng Xu wrote: > On Thu, Aug 3, 2017 at 12:03 PM, Dario Faggioli > wrote: > >=20 > > > @@ -702,14 +705,18 @@ int main_sched_rtds(int argc, char **argv) > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int *vcpus =3D (int *)xmalloc(sizeof(in= t)); /* IDs of VCPUs > > > that > > > change */ > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int *periods =3D (int *)xmalloc(sizeof(= int)); /* period is in > > > microsecond */ > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int *budgets =3D (int *)xmalloc(sizeof(= int)); /* budget is in > > > microsecond */ > > > +=C2=A0=C2=A0=C2=A0=C2=A0int *workconservings =3D (int *)xmalloc(size= of(int)); /* > > > budget is > > > in microsecond */ > > >=20 > >=20 > > Yeah, budget is in microseconds. But this is not budget! :-P >=20 > Ah, my bad.. >=20 > >=20 > > In fact (jokes apart), it can be just a bool, can't it? >=20 > Yes, bool is enough. > Is "workconserving" too long here? >=20 So, I don't want to turn this into a discussion about what colour we should paint the infamous bikeshed... but, yeah, I don't especially like this name! :-P An I mean, not only here, but everywhere you've used it (changelogs, other patches, etc.). There are two reasons for that: - it's indeed very long; - being work conserving is (or at least, I've always heard it used=C2=A0 and=C2=A0used it myself) a characteristic of a scheduling algorithm (or= =C2=A0 of its implementation), *not* of a task/vcpu/schedulable entity. It is the scheduler that is work conserving, iff it never let CPUs sit idle, when there is work to do. In our case here, the scheduler is work conserving if all the vCPUs has this flag set. It's not, if even just one has it clear. And by putting workconserving-ness at the vCPU level, it looks to me that we're doing something terminologically wrong, and=C2=A0 potentially confusing. I didn't bring this up before, because I'm a bit afraid that it's just be being picky... but since you mentioned this yourself. > I thought about alternative names, such as "wc", "workc", and > "extratime". None of them is good enough. > Yep, I agree that contractions like 'wc' or 'workc' are pretty bad. 'extratime', I'd actually like it better, TBH. > The ideal one should be much > shorter and easy to link to "work conserving". :( > If we use "extratime", it may cause confusion with the "extratime" in > the depreciated SEDF. (That is my concern of reusing the EXTRATIME in > the libxl_type.idl.) >=20 Well, but SEDF being gone (and since quite a few time), and the fact that RTDS and SEDF have not really never been there together, does leave very few room for confusion, I think. While in academia (e.g., in the GRUB =3D=3D Gready Reclaming of Unused Bandwidth papers), what you're trying to achieved, I've heard it called 'reclaiming' (as I'm sure you have as well :-)), and my friends that are still working on Linux, are actually using it in there: https://lkml.org/lkml/2017/5/18/1128 https://lkml.org/lkml/2017/5/18/1137 <-- SCHED_FLAG_RECLAIM I'm not so sure about it... As I'm not sure the meaning would appear obvious, to people not into RT scheduling research. And even from this point of view, 'extratime' seems a lot better to me. And if it were me doing this, I'd probably use it, both in the internals and in the interface. Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-aUmFLxNz01YDHcUleZIW 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 iQIcBAABCAAGBQJZhDffAAoJEBZCeImluHPuMMsQAMZwG2pMxQ3DnHaMW/3e5Xlq 68EeCwUkNLaUTneNdcWhMDvm9mkhlyggz/W/9XoX5rhPYGvZ53TNGFv6LEc387ui Q2pigKShMt09UnAPY4KTrWsaGqzf18Mcb7IW+TK85qHvgjqpiGHqWuZYtkGIzp7y vwdrwRhQKcPFhzJtO23IGLbQmEFG8Ob62YniXB84fq5UoqzDOE9lIjXD26Ut2au2 UV4tI+pybUlaskTU+GGnZp7vUCg9+o8x0phkQstmNHS+Idq3GXp8ivH7JfKoE/4M 5IbS9vo+KFFgP1iS6nNX0W43uTtQ4aFJp+gdOM8zYEioYGgvzxaTrEwWEaydSN+n fgRNjE6fC9XdmUkse6m95pf8nKPthERxxDltzEtVMAe6e0HriD6hmA0kFI/z2xka osHmDdrKOKTaL8YJkBlf1dns4qsi9b2523wSJ8wvYsTfAbPXVi/mlVX0wtk9Uc6G NnU3gKSQ8TAwlvg9V7WwSbIyMC3r2QwyBT31M3hXqAS1B0EWxwKTnhZqvekWbSuc zqXF/Xrt7GHoV+unUJcwv4AuksxTg7kTZaB82tbUbe2pKUoo8PTaVrOK1UJnmVxG D6DBSDCjzi6kNT5YcJDU9bqdUpAHwtxFc4KLbwfNuNHH2zpI4HXfQFnBG5HK3fk1 d9gd6O0zTx7wnxCOb2Zb =EQXP -----END PGP SIGNATURE----- --=-aUmFLxNz01YDHcUleZIW-- --===============7350400818548518016== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7350400818548518016==--