From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] scheduler rate controller Date: Mon, 24 Oct 2011 23:20:26 +0200 Message-ID: <1319491226.2230.62.camel@Abyss> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0521509107==" 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: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============0521509107== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8Iodr/0ZmacFf0eg7GOP" --=-8Iodr/0ZmacFf0eg7GOP Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, On Mon, 2011-10-24 at 17:17 +0100, George Dunlap wrote: > * The actual algorithm you use here isn't described. It seems to be > as follows (please correct me if I've made a mistake > reverse-engineering the algorithm): >=20 > Every 10ms, check to see if there have been more than 50 schedules. > If so, disable pre-emption entirely for 10ms, allowing processes to > run without being interrupted (unless they yield). >=20 > It seems like we should be able to do better. For one, it means in > the general case you will flip back and forth between really frequent > schedules and less frequent schedules. For two, turning off > preemption entirely will mean that whatever vcpu happens to be running > could, if it wished, run for the full 10ms; and which one got elected > to do that would be really random. =20 > To me, this is key point... Maybe we can save at least the calls coming from the timer tick from being skipped, or something like that? More generally speaking, I think I can see how this feature can be useful, and I also think it can live in the generic schedule.c code, but the algorithm with 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 one would have expected! For that reaason, although, again, a mechanism like this could (according to my opinion) be 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. 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) --=-8Iodr/0ZmacFf0eg7GOP 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) iEYEABECAAYFAk6l1poACgkQk4XaBE3IOsTR4QCgo8qwbL9coywsBY3ZRvj6KJT/ nq0An3oLLytuJJ3MwmqOXJLkLK0bhj/9 =FBhE -----END PGP SIGNATURE----- --=-8Iodr/0ZmacFf0eg7GOP-- --===============0521509107== 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 --===============0521509107==--