| Message ID | 55EDAF43.30500@arm.com |
|---|---|
| State | Accepted |
| Commit | 231678b768da07d19ab5683a39eeb0c250631d02 |
| Headers | show |
On 7 September 2015 at 17:37, Dietmar Eggemann <dietmar.eggemann@arm.com> wrote: > On 04/09/15 00:51, Steve Muckle wrote: >> Hi Morten, Dietmar, >> >> On 08/14/2015 09:23 AM, Morten Rasmussen wrote: >> ... >>> + * cfs_rq.avg.util_avg is the sum of running time of runnable tasks plus the >>> + * recent utilization of currently non-runnable tasks on a CPU. It represents >>> + * the amount of utilization of a CPU in the range [0..capacity_orig] where >> >> I see util_sum is scaled by SCHED_LOAD_SHIFT at the end of >> __update_load_avg(). If there is now an assumption that util_avg may be >> used directly as a capacity value, should it be changed to >> SCHED_CAPACITY_SHIFT? These are equal right now, not sure if they will >> always be or if they can be combined. > > You're referring to the code line > > 2647 sa->util_avg = (sa->util_sum << SCHED_LOAD_SHIFT) / LOAD_AVG_MAX; > > in __update_load_avg()? > > Here we actually scale by 'SCHED_LOAD_SCALE/LOAD_AVG_MAX' so both values are > load related. I agree with Steve that there is an issue from a unit point of view sa->util_sum and LOAD_AVG_MAX have the same unit so sa->util_avg is a load because of << SCHED_LOAD_SHIFT) Before this patch , the translation from load to capacity unit was done in get_cpu_usage with "* capacity) >> SCHED_LOAD_SHIFT" So you still have to change the unit from load to capacity with a "/ SCHED_LOAD_SCALE * SCHED_CAPACITY_SCALE" somewhere. sa->util_avg = ((sa->util_sum << SCHED_LOAD_SHIFT) /SCHED_LOAD_SCALE * SCHED_CAPACITY_SCALE / LOAD_AVG_MAX = (sa->util_sum << SCHED_CAPACITY_SHIFT) / LOAD_AVG_MAX; Regards, Vincent > > LOAD (UTIL) and CAPACITY have the same SCALE and SHIFT values because > SCHED_LOAD_RESOLUTION is always defined to 0. scale_load() and > scale_load_down() are also NOPs so this area is probably > worth a separate clean-up. > Beyond that, I'm not sure if the current functionality is > broken if we use different SCALE and SHIFT values for LOAD and CAPACITY? > >> >>> + * capacity_orig is the cpu_capacity available at * the highest frequency >> >> spurious * >> >> thanks, >> Steve >> > > Fixed. > > Thanks, > > -- Dietmar > > -- >8 -- > > From: Dietmar Eggemann <dietmar.eggemann@arm.com> > Date: Fri, 14 Aug 2015 17:23:13 +0100 > Subject: [PATCH] sched/fair: Get rid of scaling utilization by capacity_orig > > Utilization is currently scaled by capacity_orig, but since we now have > frequency and cpu invariant cfs_rq.avg.util_avg, frequency and cpu scaling > now happens as part of the utilization tracking itself. > So cfs_rq.avg.util_avg should no longer be scaled in cpu_util(). > > Cc: Ingo Molnar <mingo@redhat.com> > Cc: Peter Zijlstra <peterz@infradead.org> > Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> > Signed-off-by: Morten Rasmussen <morten.rasmussen@arm.com> > --- > kernel/sched/fair.c | 38 ++++++++++++++++++++++---------------- > 1 file changed, 22 insertions(+), 16 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 2074d45a67c2..a73ece2372f5 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4824,33 +4824,39 @@ static int select_idle_sibling(struct task_struct *p, int target) > done: > return target; > } > + > /* > * cpu_util returns the amount of capacity of a CPU that is used by CFS > * tasks. The unit of the return value must be the one of capacity so we can > * compare the utilization with the capacity of the CPU that is available for > * CFS task (ie cpu_capacity). > - * cfs.avg.util_avg is the sum of running time of runnable tasks on a > - * CPU. It represents the amount of utilization of a CPU in the range > - * [0..SCHED_LOAD_SCALE]. The utilization of a CPU can't be higher than the > - * full capacity of the CPU because it's about the running time on this CPU. > - * Nevertheless, cfs.avg.util_avg can be higher than SCHED_LOAD_SCALE > - * because of unfortunate rounding in util_avg or just > - * after migrating tasks until the average stabilizes with the new running > - * time. So we need to check that the utilization stays into the range > - * [0..cpu_capacity_orig] and cap if necessary. > - * Without capping the utilization, a group could be seen as overloaded (CPU0 > - * utilization at 121% + CPU1 utilization at 80%) whereas CPU1 has 20% of > - * available capacity. > + * > + * cfs_rq.avg.util_avg is the sum of running time of runnable tasks plus the > + * recent utilization of currently non-runnable tasks on a CPU. It represents > + * the amount of utilization of a CPU in the range [0..capacity_orig] where > + * capacity_orig is the cpu_capacity available at the highest frequency > + * (arch_scale_freq_capacity()). > + * The utilization of a CPU converges towards a sum equal to or less than the > + * current capacity (capacity_curr <= capacity_orig) of the CPU because it is > + * the running time on this CPU scaled by capacity_curr. > + * > + * Nevertheless, cfs_rq.avg.util_avg can be higher than capacity_curr or even > + * higher than capacity_orig because of unfortunate rounding in > + * cfs.avg.util_avg or just after migrating tasks and new task wakeups until > + * the average stabilizes with the new running time. We need to check that the > + * utilization stays within the range of [0..capacity_orig] and cap it if > + * necessary. Without utilization capping, a group could be seen as overloaded > + * (CPU0 utilization at 121% + CPU1 utilization at 80%) whereas CPU1 has 20% of > + * available capacity. We allow utilization to overshoot capacity_curr (but not > + * capacity_orig) as it useful for predicting the capacity required after task > + * migrations (scheduler-driven DVFS). > */ > static int cpu_util(int cpu) > { > unsigned long util = cpu_rq(cpu)->cfs.avg.util_avg; > unsigned long capacity = capacity_orig_of(cpu); > > - if (util >= SCHED_LOAD_SCALE) > - return capacity; > - > - return (util * capacity) >> SCHED_LOAD_SHIFT; > + return (util >= capacity) ? capacity : util; > } > > /* > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 2074d45a67c2..a73ece2372f5 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4824,33 +4824,39 @@ static int select_idle_sibling(struct task_struct *p, int target) done: return target; } + /* * cpu_util returns the amount of capacity of a CPU that is used by CFS * tasks. The unit of the return value must be the one of capacity so we can * compare the utilization with the capacity of the CPU that is available for * CFS task (ie cpu_capacity). - * cfs.avg.util_avg is the sum of running time of runnable tasks on a - * CPU. It represents the amount of utilization of a CPU in the range - * [0..SCHED_LOAD_SCALE]. The utilization of a CPU can't be higher than the - * full capacity of the CPU because it's about the running time on this CPU. - * Nevertheless, cfs.avg.util_avg can be higher than SCHED_LOAD_SCALE - * because of unfortunate rounding in util_avg or just - * after migrating tasks until the average stabilizes with the new running - * time. So we need to check that the utilization stays into the range - * [0..cpu_capacity_orig] and cap if necessary. - * Without capping the utilization, a group could be seen as overloaded (CPU0 - * utilization at 121% + CPU1 utilization at 80%) whereas CPU1 has 20% of - * available capacity. + * + * cfs_rq.avg.util_avg is the sum of running time of runnable tasks plus the + * recent utilization of currently non-runnable tasks on a CPU. It represents + * the amount of utilization of a CPU in the range [0..capacity_orig] where + * capacity_orig is the cpu_capacity available at the highest frequency + * (arch_scale_freq_capacity()). + * The utilization of a CPU converges towards a sum equal to or less than the + * current capacity (capacity_curr <= capacity_orig) of the CPU because it is + * the running time on this CPU scaled by capacity_curr. + * + * Nevertheless, cfs_rq.avg.util_avg can be higher than capacity_curr or even + * higher than capacity_orig because of unfortunate rounding in + * cfs.avg.util_avg or just after migrating tasks and new task wakeups until + * the average stabilizes with the new running time. We need to check that the + * utilization stays within the range of [0..capacity_orig] and cap it if + * necessary. Without utilization capping, a group could be seen as overloaded + * (CPU0 utilization at 121% + CPU1 utilization at 80%) whereas CPU1 has 20% of + * available capacity. We allow utilization to overshoot capacity_curr (but not + * capacity_orig) as it useful for predicting the capacity required after task + * migrations (scheduler-driven DVFS). */ static int cpu_util(int cpu) { unsigned long util = cpu_rq(cpu)->cfs.avg.util_avg; unsigned long capacity = capacity_orig_of(cpu); - if (util >= SCHED_LOAD_SCALE) - return capacity; - - return (util * capacity) >> SCHED_LOAD_SHIFT; + return (util >= capacity) ? capacity : util; } /*