Thanks Dario for your helpful comments.
> 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?
> 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.
> 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.
>
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. :)
> 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)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home