RE: [PATCH] scheduler rate controller

[Dario Faggioli <raistlin@linux.it>]

[-- Attachment #1.1: Type: text/plain, Size: 2686 bytes --]

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?
> > 
> 
> Yes, it makes sense. But currently, we lacks the scheduler knowledge such as what caused the scheduler, timer or interrupt? Can we?
> 
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).
> > 
> 
> One question is that, what is the right palace to document such information? I'd like to make it as clear as possible to the users.
> 
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 the disasters to any of the existing schedulers.
> I'm fine to move it to the credit in the current stage. :)
> 
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

-- 
<<This happens because I choose it to happen!>> (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)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel