From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] RFC: Automatically adjust dom0 weight Date: Fri, 10 Feb 2012 09:31:47 +0100 Message-ID: <1328862707.2863.57.camel@Solace> References: <0aa2ccb5622461801936.1328790671@elijah> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0463247509246784766==" Return-path: In-Reply-To: <0aa2ccb5622461801936.1328790671@elijah> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: George Dunlap Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============0463247509246784766== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-OHaDVJbhWlD5bENcFSmQ" --=-OHaDVJbhWlD5bENcFSmQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-02-09 at 12:31 +0000, George Dunlap wrote: > At the moment, the scheduler treats dom0 the same as any other VM > for the purposes of accounting. Since dom0 is really a critical > piece of infrastructure, and a part of the hypervisor system as a > whole, it would make more sense to try to give dom0 special rights > wrt CPU time. >=20 To me, this seems more a sensible configuration than a feature to be embedded in the scheduler. I agree that dom0 always getting some CPU time is critical in many ways, but I think the scheduler should provide effective means for achieving such goal and then it is up to toolstack, sysadmin, etc, to use them appropriately. I obviously may be wrong, but I see this as a clear example of implementing a policy, while we should just provide mechanisms. :-) > This patch will cause the hypervisor to automatically adjust the > weight of dom0 such that it should be able to get either enough > cpu for each of its vcpus, or half of the cpus on the system, > whichever is less. >=20 That's the point. In fact, I think credit has the proper mechanisms to affect the CPU time a domain receives, but not in such a way that the above is achieved, and here's why this needs to be done by modifying he scheduler (am I wrong?). It's sort of in replacement of a "minimum guaranteed CPU bandwidth" for a domain mechanism, which maybe is too complex/not worthwhile to put in place in a generalized fashion. Just to clarify with an example, in sedf you wouldn't need anything like this, as you specify exactly the _guaranteed_ CPU bandwidth[*] each vcpu should be entitled with, i.e., sedf implements the correct mechanism for enforcing a policy like that one, established by someone else up in the stack... Then obviously sedf has a whole bunch of limitations, and we all know it. :-P Another way of looking at it could be, would user expect that? I mean seeing dom0's weights dynamically changing? But here I really don't have the proper backup for providing an answer... :-) > I'm mostly posting to see what the interest in this kind of approach > is. If there is interest, I'll do the work to make it more configurable. >=20 Yes, if we want this, I think it at least should be possible to turn it on and off (although then the question becomes what the default should be). Summarizing, if something not equal, but maybe equally effective, could be achieved without this (e.g., http://wiki.xen.org/wiki/Xen_Best_Practices), I'd be happy not having it. However, if we think it could be useful and it is configurable enough, I can live with it. :-) Regards, Dario [*] For current implementation of sedf, that is true. If that scheduler would ever properly support SMP, it will need some more tweaking to stay true, or it will just become "a bit less true" :-D --=20 <> (Raistlin Majere) ------------------------------------------------------------------- Dario Faggioli, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy) --=-OHaDVJbhWlD5bENcFSmQ 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 v1.4.11 (GNU/Linux) iEYEABECAAYFAk801fMACgkQk4XaBE3IOsRFtACgosD7PSLCyizOFn6YdxB8LCjb AnEAn3mBVRmzwoG+LEPW1+Uz3Aoi2ReB =9tW5 -----END PGP SIGNATURE----- --=-OHaDVJbhWlD5bENcFSmQ-- --===============0463247509246784766== 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.xensource.com http://lists.xensource.com/xen-devel --===============0463247509246784766==--