On 23 October 2015 at 17:29, Juri Lelli juri.lelli@arm.com wrote:
Hi,
On 23/10/15 16:09, Vincent Guittot wrote:
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 ?
In principle I'd say yes. Unfortunately, the deadline < period case has not been yet fully analized from a theoretical point of view, so we currently have implemented the thing that is theoretically sound. SCHED_DEADLINE doesn't even strictly guarantee deadlines on SMP systems already (only a bounded tardiness is guaranteed), so I'd say we can play simpler for the time being and keep dl_bw as runtime/period. Maybe some concrete use-case will drive research on these bits as soon as we really start using this thing ;-).
Yes, I was initially wondering why runtime/period was used in the scheduler and i have seen the reasons in the deadline scheduler documentation. My comment was more referring to the patch "track the active utilisation" where you use the sum of sched_entity dl_bw. With this metric, we will not be able to ensure the deadline constraint. You should at least use runtime/deadline as proposed in "fix active utilization tracking" even though i'm not sure that's enough in all cases. As discussed previously, my branch contains 1 patch "use deadline bandwidth in scale_rt_capacity" that tracks the sum of dl_bw of tasks on a CPU whatever the state. Then i use this metric in scale_rt_capacity and remove the execution time of deadline task from rt_avg. Once deadline tasks are removed from rt_avg, i can use rt_avg to evaluate the rt task utilization and set the capacity requirement ofr rt scheduler.
Regards, Vincent
Thanks for the branch above, I'll start playing with it week after next.
Best,
- Juri
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. >