On 10/12/2015 06:55 AM, Vincent Guittot wrote:
For the RT story, are you thinking to use rq->rt_avg in some way?
Yes that was my goal but the deadline is also accounted in rq->rt_avg which is then used in scale_rt_capacity. I was planning to remove the deadline class from rq->rt_avg and to use the per cpu deadline bandwidth in scale_rt_capacity instead
If the deadline contribution to rq->rt_avg is left in place, can RT and deadline both be accounted for via that one mechanism for the purposes of sched-dvfs?
I'm not sure how the accuracy/behavior of the deadline accounting to rq->rt_avg differs from the forthcoming patchset Juri mentioned, but if it's not as good, perhaps the mechanisms could be combined so that rt_avg (and by extension the per-CPU capacity adjustments in CFS) benefit as well.
On 12/10/15 17:24, Steve Muckle wrote:
On 10/12/2015 06:55 AM, Vincent Guittot wrote:
For the RT story, are you thinking to use rq->rt_avg in some way?
Yes that was my goal but the deadline is also accounted in rq->rt_avg which is then used in scale_rt_capacity. I was planning to remove the deadline class from rq->rt_avg and to use the per cpu deadline bandwidth in scale_rt_capacity instead
If the deadline contribution to rq->rt_avg is left in place, can RT and deadline both be accounted for via that one mechanism for the purposes of sched-dvfs?
I'd keep them separate, as the DEADLINE part is much more accurate than RT (and CFS). IMHO, using rt_avg for driving sched-dvfs is still trying to make up for the fact that RT lacks a more accurate PELT; so we need to try to use this other running avg thing, at least in the short run.
I'm not sure how the accuracy/behavior of the deadline accounting to rq->rt_avg differs from the forthcoming patchset Juri mentioned, but if it's not as good, perhaps the mechanisms could be combined so that rt_avg (and by extension the per-CPU capacity adjustments in CFS) benefit as well.
The fact with DEADLINE is that it actually doesn't track anything, it just enforce a max utilization, and this is what can be used to ask for a minimum capacity. So, I fear there is little space for combining the two things, but splitting them, as Vincent is proposing, seems to make sense to me.
Best,
- Juri
On 10/12/2015 09:45 AM, Juri Lelli wrote:
If the deadline contribution to rq->rt_avg is left in place, can RT and deadline both be accounted for via that one mechanism for the purposes of sched-dvfs?
I'd keep them separate, as the DEADLINE part is much more accurate than RT (and CFS). IMHO, using rt_avg for driving sched-dvfs is still trying to make up for the fact that RT lacks a more accurate PELT; so we need to try to use this other running avg thing, at least in the short run.
I'm not sure how the accuracy/behavior of the deadline accounting to rq->rt_avg differs from the forthcoming patchset Juri mentioned, but if it's not as good, perhaps the mechanisms could be combined so that rt_avg (and by extension the per-CPU capacity adjustments in CFS) benefit as well.
The fact with DEADLINE is that it actually doesn't track anything, it just enforce a max utilization, and this is what can be used to ask for a minimum capacity. So, I fear there is little space for combining the two things, but splitting them, as Vincent is proposing, seems to make sense to me.
Agreed, I didn't read Vincent's comment closely enough and also wasn't thinking about how rt_avg is maintained, which prevents the more accurate DEADLINE requirement from simply being added in. My concern was just that the improved DEADLINE predictions be used not only for sched-dvfs but also for scaling the capacity in CFS but Vincent's proposal will take care of that.
One minor suggestion, perhaps scale_rt_capacity could be renamed more accurately as scale_rt_dl_capacity as part of the series.
On 12 October 2015 at 22:10, Steve Muckle steve.muckle@linaro.org wrote:
On 10/12/2015 09:45 AM, Juri Lelli wrote:
If the deadline contribution to rq->rt_avg is left in place, can RT and deadline both be accounted for via that one mechanism for the purposes of sched-dvfs?
I'd keep them separate, as the DEADLINE part is much more accurate than RT (and CFS). IMHO, using rt_avg for driving sched-dvfs is still trying to make up for the fact that RT lacks a more accurate PELT; so we need to try to use this other running avg thing, at least in the short run.
I'm not sure how the accuracy/behavior of the deadline accounting to rq->rt_avg differs from the forthcoming patchset Juri mentioned, but if it's not as good, perhaps the mechanisms could be combined so that rt_avg (and by extension the per-CPU capacity adjustments in CFS) benefit as well.
The fact with DEADLINE is that it actually doesn't track anything, it just enforce a max utilization, and this is what can be used to ask for a minimum capacity. So, I fear there is little space for combining the two things, but splitting them, as Vincent is proposing, seems to make sense to me.
Agreed, I didn't read Vincent's comment closely enough and also wasn't thinking about how rt_avg is maintained, which prevents the more accurate DEADLINE requirement from simply being added in. My concern was just that the improved DEADLINE predictions be used not only for sched-dvfs but also for scaling the capacity in CFS but Vincent's proposal will take care of that.
One minor suggestion, perhaps scale_rt_capacity could be renamed more accurately as scale_rt_dl_capacity as part of the series.
I'm not sure that it's worth changing. The 1st reason is that deadline is a RT sched class like fifo and rr but with more description of the task constraints. Then, scale_rt_capacity can also be impacted by irq and steal time so if we want to be precise, it should become scale_rt_dl_irq_steal_capacity which is a bit long IMHO.
Regards, Vincent
On 10/13/2015 11:55 PM, Vincent Guittot wrote:
One minor suggestion, perhaps scale_rt_capacity could be renamed more accurately as scale_rt_dl_capacity as part of the series.
I'm not sure that it's worth changing. The 1st reason is that deadline is a RT sched class like fifo and rr but with more description of the task constraints. Then, scale_rt_capacity can also be impacted by irq and steal time so if we want to be precise, it should become scale_rt_dl_irq_steal_capacity which is a bit long IMHO.
RT and DL are still separate sched classes though... But I agree that a different name would be more appropriate given irq and steal time. Perhaps I'll float a patch if there's a chance later on.
-
Juri Lelli -
Steve Muckle -
Vincent Guittot