From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: RE: [PATCH] scheduler rate controller Date: Mon, 31 Oct 2011 11:16:36 +0100 Message-ID: <1320056196.15109.34.camel@Abyss> References: <1319789425.19320.12.camel@Abyss> <1319796584.19320.31.camel@Abyss> <1319818714.21033.414.camel@elijah> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0468922175==" 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" , George Dunlap , "Duan, Jiangang" List-Id: xen-devel@lists.xenproject.org --===============0468922175== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AVDXRWCClejGJ+IvAZFz" --=-AVDXRWCClejGJ+IvAZFz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2011-10-29 at 10:05 +0800, Lv, Hui wrote: > As you said, if applying the seveal_ms_delay, it will happen whenever sys= tem is normal or not (excessive frequency). It may possible have the conseq= uence that 1)under normal condition, it will produce worse Qos than that wi= thout applying such delay, 2) under excessive frequency condition, the miti= gation effect of 1ms-delay may be too weak. In addition, your idea is to de= lay scheduling instead of reducing, which means the total number of schedul= ing would probably not change. > I think it would. I mean, all the interrupts that arrive (and that are causing TASKLET_SCHEDULE->schedule() right now) and see current vcpu not having run for 1ms would collapse in just one call to schedule() at the end of the 1ms delay from the time instant when the very first one (interrupt) happened... Isn't it? If yes, that would definitely reduce the number of calls to schedule(). > I think one possible solution, is to make the value of 1ms-delay adaptive= according to the system status (low load or high load). If so, SRC patch j= ust covered the excessive condition currently :). That's why I mentioned to= treat normal and excessive conditions separately and don't influence the n= ormal case as much as possible. Because we never know the consequence witho= ut amount of testing work. :) >=20 Well, again, from my perspective, these numbers (1ms, 10ms) really looks like ages, considering for example audio processing workloads with software like JACK needs periodicity of 1.3 or 2.6 ms, and thus having 1ms or (for worse) 10ms eaten by the scheduler would definitely step on their toes. I understand we're not talking very much about audio processing VMs here but hey, if it has to be general purpose... :-P > Some of my stupid thinking :) >=20 Same for mine. :-) 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) --=-AVDXRWCClejGJ+IvAZFz 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) iEYEABECAAYFAk6udYQACgkQk4XaBE3IOsRjGgCggItGz/6uMML+a4cZTemRkxpw TEIAnA3vOg5/fwz78+lENpyLDWdh6CmE =uJjt -----END PGP SIGNATURE----- --=-AVDXRWCClejGJ+IvAZFz-- --===============0468922175== 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 --===============0468922175==--