From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: RE: [PATCH] scheduler rate controller Date: Fri, 28 Oct 2011 10:10:25 +0200 Message-ID: <1319789425.19320.12.camel@Abyss> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1800198280==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Lv, Hui" Cc: "Tian, Kevin" , "xen-devel@lists.xensource.com" , "keir@xen.org" , George Dunlap , "Dong, Eddie" , "Duan, Jiangang" List-Id: xen-devel@lists.xenproject.org --===============1800198280== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-dz5eCxUnYmjbB5Q5YNqC" --=-dz5eCxUnYmjbB5Q5YNqC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2011-10-28 at 10:07 +0800, Lv, Hui wrote: > Yes, agree that, there are more things to do to make a more delicate solu= tion for this in the next step.=20 > Hi Hui, Firt of ll, I took a look at the slides and it really seems there's a huge amount of work there about benchmarking, analyzing the results and chasing the culprits of the various sources of overhead... Great job, indeed! :-) > For example, we can consider per VM status to decide whether to turn on/o= ff the control to make it more fair, such as your point three. >=20 > However, as the first step, the current solution is straightforward and e= ffective.=20 > 1) Most importantly, it happens when the scheduling frequency is excessiv= e. User can decide which degree is excessive by setting parameter "opt_sche= d_rate_high"(default 50). If the system is crucial for latency sensitive ta= sks, you can choose a higher value that this patch will have little impact = on it. User can decide which value is good for their environment. However, = from our experience, if the scheduling frequency is too excessive, it also = impairs the Qos of latency sensitive tasks due to frequent interrupts by ot= her VMs. > 2) Considering the excessive scheduling condition, the preemption is turn= ing off entirely. If current running vcpu, yielded frequently, it cannot ru= n for the full 10ms. If current running vcpu, not yielded frequently, it ca= n possible run as long as up to 10ms. That means, this algorithm roughly pr= otect the un-yielded vcpu to run a long time slice without preemption. This= is something similar to your point 3 but in a roughly way. :) > 3) Finally, this patch aimed to solve the issue when scheduling frequency= is excessive but not influence the normal case (less frequency). We should= treat these two cases separately. Since excessive scheduling case cannot g= uarantee neither performance or Qos. >=20 Just something crossed my mind reading the patch and the comments, would it make sense to rate-limit the calls coming from (non-timer) interrupt exit paths while still letting the tick able to trigger a scheduling decision? This just to be sure that at least the time slice enforcing (if any) happens how expected... Could it make sense? More generally speaking, I see how this feature can be useful, and I also think it could live in the generic schedule.c code, but (as George was saying) the algorithm by which rate-limiting is happening needs to be well known, documented and exposed to the user (more than by means of a couple of perf-counters). For example this might completely destroy the time guarantees a scheduler like sEDF would give, and in such case it must be easy enough to figure out what's going on and why the scheduler is not behaving as expected! For that reason, although again, this could be made general enough to be sensible and meaningful for all the various schedulers, it might be worthwhile to have it inside credit1 for now, where we know it will probably yield the most of its benefits. Just my 2 cents. :-) Thanks and Regards, Dario --=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) --=-dz5eCxUnYmjbB5Q5YNqC 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) iEYEABECAAYFAk6qY3EACgkQk4XaBE3IOsTE2gCbB73d1gSW0XPdvWq7/hF9nyck cr8AniyqhBzjw2IiSfW/KdLt+ueHr2eP =/04C -----END PGP SIGNATURE----- --=-dz5eCxUnYmjbB5Q5YNqC-- --===============1800198280== 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 --===============1800198280==--