Hi Juri
On 20 October 2015 at 17:58, Vincent Guittot vincent.guittot@linaro.org wrote:
On 20 October 2015 at 17:31, Juri Lelli juri.lelli@arm.com wrote:
Hi,
[snip]
Using a min value just mean that we are not able to evaluate the current capacity requirement of the deadline class and that we will just steal the capacity requested by other class which is not a good solution IMHO
Juri, what will be the granularity of the computation of the bandwidth of the patches you are going to send ?
I'm not sure I get what you mean by granularity here. The patches will add a 0..100% bandwidth number, that we'll have to normalize to 0..1024, for SCHED_DEADLINE tasks currently active. Were you expecting something else?
My question was more about time granularity than range: Is the bandwidth statically define with deadline parameters of the tasks or is it updated once task has consumed its runtime budget of the current period ? But you have answered to my question in your former comments
I pushed patches that add bandwidth tracking for SCHED_DEADLINE here:
git://linux-arm.org/linux-jl.git wip/dl_track_bw
Top three patches are what should be enough for having information about DL usage (top two one are actually debug stuff). We just need to convert from [0..1<<20] (DL bandwidth scale) to [0..1024].
Please let me know if they make any sense to you, and the others :-).
Thanks, i'm going to have a look at the patches and try it in order to have some 1st feedback for next sync call
I have pushed a draft version of rt sched dvfs patchset here: https://git.linaro.org/people/vincent.guittot/kernel.git/shortlog/refs/heads...
This branch contains both steve's and juri's patches as well as a 1st draft version of my patches for RT scheduler dvfs.
Juri, I have one comment about your patches. They use the runtime/period bandwidth to calculate the needed capacity of runnable tasks but shouldn't they use the runtime/deadline bandwidth instead ? Otherwise, the deadline tasks could miss its deadline. If we have a 2ms running task with a deadline of 4ms and a period of 10ms, you patch tracks a needed bandwidth of 20% whereas it should track 50% to be sure to not miss the deadline (let assume a smp system to not increase the complexity of the use case).
Regards, Vincent
Regards, Vincent
Best,
- Juri
Thanks Vincent
Thanks,
- Juri
As Vincent points out, RT is a bit tricky. AFAIK, it doesn't have any utilization tracking at all. I think we have to fix that somehow. Regarding responsiveness, RT doesn't provide any guarantees by design (in the same way deadline does) so we shouldn't be violating any policies by slowing RT tasks down. The users might not be happy though so we could favor performance for RT tasks to avoid breaking legacy software and ask users that care about energy to migrate to deadline where we actually know the performance constraints of the tasks.