From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v6 for Xen 4.7 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler Date: Tue, 15 Mar 2016 17:41:32 +0100 Message-ID: <1458060092.3102.721.camel@citrix.com> References: <1457286958-5427-1-git-send-email-lichong659@gmail.com> <1457286958-5427-2-git-send-email-lichong659@gmail.com> <20160308190950.GT31271@citrix.com> <1457539804.3102.425.camel@citrix.com> <56E05F8F02000078000DAF15@prv-mh.provo.novell.com> <56E6866202000078000DBECD@prv-mh.provo.novell.com> <1457946623.3102.636.camel@citrix.com> <56E68F5202000078000DBF46@prv-mh.provo.novell.com> <1457949930.3102.641.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1605013802857712398==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Chong Li Cc: Chong Li , Wei Liu , Sisu Xi , GeorgeDunlap , xen-devel , Meng Xu , Jan Beulich , Dagaen Golomb List-Id: xen-devel@lists.xenproject.org --===============1605013802857712398== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SqOXxKeFtphoTNVQSWM+" --=-SqOXxKeFtphoTNVQSWM+ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-03-15 at 11:22 -0500, Chong Li wrote: > On Mon, Mar 14, 2016 at 5:05 AM, Dario Faggioli > wrote: > >=C2=A0 > > However, for this specific case, I was also considering that, and I > > agree, if possible/not to difficult to implement, once per domain > > would > > indeed be better. > >=20 > It is easy to implement a global "warn_on_once". >=20 Sure. > To implement a per-domain "warn_on_once", I may need a hash table > (name it as "dom_warned"), and dom_warned[domid] returns true or > false. > I don't know if hash table is supported in Xen. Or do we have any > list > structure which is very good at searching? >=20 And all this just for having _this_ specific warning printed once per domain. No, I don't think it is worth... Or maybe it is, but I don't think it's fair to ask you to do it. Or maybe, if you're up for doing it, then you're free to, but I don't think it's fair to ask for it as prerequisite for this patch. :-) > Another way is to add a "bool" field in struct domain, but I don't > think that would be a good design. >=20 Yeah, I like it even less. :-/ We said 'once' and then 'once per domain', but something I'd be fine with (coupled with keeping G_WARNING) would be 'once per operation'. Basically, if a domain has 128 vcpus, and an hypercall tries to set all of them to period=3D100, budget=3D50, we just print the warning once. Then, if after a while the sysadmin tries the same again, we again just log once, etc. Doing this seems much easier, as the 'warned' flag could just be a local variable of the hypercall implementation. I'm quite sure that would work if there is not any continuation/re-issueing mechanism in the hypercall in question. BUT in our case there is, so things may be more complicated... :-/ Had you thought about a solution like this already? If no, can you see whether there is a nice and easy way to make something like what I just described above to work in our case? If we find nothing, we'll think at alternatives, including killing the waning. 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) --=-SqOXxKeFtphoTNVQSWM+ 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 iEYEABECAAYFAlboOz0ACgkQk4XaBE3IOsRopQCfSosl90cOzcFBFROxprwJtlv4 4bkAn1mpXi/g+XQ4vQfrbJCKr9m72kpQ =2dQr -----END PGP SIGNATURE----- --=-SqOXxKeFtphoTNVQSWM+-- --===============1605013802857712398== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============1605013802857712398==--