From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: RE: [PATCH] scheduler rate controller Date: Fri, 28 Oct 2011 12:09:44 +0200 Message-ID: <1319796584.19320.31.camel@Abyss> References: <1319789425.19320.12.camel@Abyss> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0914252001==" 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 --===============0914252001== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-2YqhjpPiLYuGu/xiQIgm" --=-2YqhjpPiLYuGu/xiQIgm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2011-10-28 at 16:52 +0800, Lv, Hui wrote: > > 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? > >=20 >=20 > Yes, it makes sense. But currently, we lacks the scheduler knowledge such= as what caused the scheduler, timer or interrupt? Can we? >=20 Not sure yet, I can imagine it's tricky and I need to dig a bit more in the code, but I'll let know if I found a way of doing that... > > 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). > >=20 >=20 > One question is that, what is the right palace to document such informati= on? I'd like to make it as clear as possible to the users. >=20 Well, don't know, maybe a WARN (a WARN_ONCE alike thing would probably be better), or in general something that leave a footstep in the logs, so that one can find out by means of `xl dmesg' or related. Obviously, I'm not suggesting of printk-ing each suppressed schedule invocation, or the overhead would get even worse... :-P I'm thinking of something that happens the very first time the limiting fires, or maybe oncee some period/number of suppressions, just to remind the user that he's getting weird behaviour because _he_enabled_ rate-limiting. Hopefully, that might also be useful for the user itself to fine tune the limiting parameters, although I think the perf-counters are already quite well suited for this. > I think I got your point. More considerations should be taken to avoid th= e disasters to any of the existing schedulers. > I'm fine to move it to the credit in the current stage. :) >=20 Yeah, and sorry (to everyone) for having pointed that out in so many messages very similar to each other, but I was having MUA issues and was thinking my mails weren't making to the list... Sorry again, 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) --=-2YqhjpPiLYuGu/xiQIgm 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) iEYEABECAAYFAk6qf2gACgkQk4XaBE3IOsQIJwCfRwvtW6WZHFX+/XuH8Kh/JdfP MfkAn1k/z/Kst9QlrgsV0vQ8mc2byXt6 =KNWc -----END PGP SIGNATURE----- --=-2YqhjpPiLYuGu/xiQIgm-- --===============0914252001== 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 --===============0914252001==--