RE: [PATCH] scheduler rate controller

[Dario Faggioli <raistlin@linux.it>]

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

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 solution for this in the next step. 
>
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/off the control to make it more fair, such as your point three.
> 
> However, as the first step, the current solution is straightforward and effective. 
> 1) Most importantly, it happens when the scheduling frequency is excessive. User can decide which degree is excessive by setting parameter "opt_sched_rate_high"(default 50). If the system is crucial for latency sensitive tasks, 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 other VMs.
> 2) Considering the excessive scheduling condition, the preemption is turning off entirely. If current running vcpu, yielded frequently, it cannot run for the full 10ms. If current running vcpu, not yielded frequently, it can possible run as long as up to 10ms. That means, this algorithm roughly protect 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 guarantee neither performance or Qos.
> 
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

-- 
<<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