lkml.org 
[lkml]   [2019]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH 3/3] sched/fair: Consider uclamp for "task fits capacity" checks
On Thursday 21 Nov 2019 at 14:51:06 (+0000), Valentin Schneider wrote:
> On 21/11/2019 13:30, Quentin Perret wrote:
> > On Thursday 21 Nov 2019 at 12:56:39 (+0000), Valentin Schneider wrote:
> >>> @@ -6274,6 +6274,15 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
> >>> if (!fits_capacity(util, cpu_cap))
> >>> continue;
> >>>
> >>> + /*
> >>> + * Skip CPUs that don't satisfy uclamp requests. Note
> >>> + * that the above already ensures the CPU has enough
> >>> + * spare capacity for the task; this is only really for
> >>> + * uclamp restrictions.
> >>> + */
> >>> + if (!task_fits_capacity(p, capacity_orig_of(cpu)))
> >>> + continue;
> >>
> >> This is partly redundant with the above, I think. What we really want here
> >> is just
> >>
> >> fits_capacity(uclamp_eff_value(p, UCLAMP_MIN), capacity_orig_of(cpu))
> >>
> >> but this would require some inline #ifdeffery.
> >
> > This suggested change lacks the UCLAMP_MAX part, which is a shame
> > because this is precisely in the EAS path that we should try and
> > down-migrate tasks if they have an appropriate max_clamp. So, your first
> > proposal made sense, IMO.
> >
>
> Hm right, had to let that spin in my head for a while but I think I got it.
>
> I was only really thinking of:
>
> (h960: LITTLE = 462 cap, big = 1024)
> p.uclamp.min = 512 -> skip LITTLEs regardless of the actual util_est
>
> but your point is we also want stuff like:
>
> p.uclamp.max = 300 -> accept LITTLEs regardless of the actual util_est

Right, sorry if my message wasn't clear.

> I'll keep the feec() change as-is and add something like the above in the
> changelog for v2.
>
> > Another option to avoid the redundancy would be to do something along
> > the lines of the totally untested diff below.
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 69a81a5709ff..38cb5fe7ba65 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -6372,9 +6372,12 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
> > if (!cpumask_test_cpu(cpu, p->cpus_ptr))
> > continue;
> >
> > - /* Skip CPUs that will be overutilized. */
> > util = cpu_util_next(cpu, p, cpu);
> > cpu_cap = capacity_of(cpu);
> > + spare_cap = cpu_cap - util;
> > + util = uclamp_util_with(cpu_rq(cpu), util, p);
> > +
> > + /* Skip CPUs that will be overutilized. */
> > if (!fits_capacity(util, cpu_cap))
> > continue;
> >
> > @@ -6389,7 +6392,6 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
> > * Find the CPU with the maximum spare capacity in
> > * the performance domain
> > */
> > - spare_cap = cpu_cap - util;
> > if (spare_cap > max_spare_cap) {
> > max_spare_cap = spare_cap;
> > max_spare_cap_cpu = cpu;
> >
> > Thoughts ?
> >
>
> uclamp_util_with() (or uclamp_rq_util_with() ;)) picks the max between the
> rq-aggregated clamps and the task clamps, which isn't what we want. If the
> task has a low-ish uclamp.max (e.g. the 300 example from above) but the
> rq-wide max-aggregated uclamp.max is ~800, we'd clamp using that 800. It
> makes sense for frequency selection, but not for task placement IMO.

Right, but you could argue that this is in fact a correct behaviour.
What we want to know is 'is this CPU big enough to meet the capacity
request if I enqueue p there ?'. And the 'capacity request' is the
aggregated rq-wide clamped util, IMO.

If enqueuing 'p' on a given CPU will cause the rq-wide clamped util to
go above the CPU capacity, we want to skip that CPU.

The obvious case is if p's min_clamp is larger than the CPU capacity.

But similarly, if p's max_clamp is going to be ignored because of
another task with a larger max_clamp on the same rq, this is relevant
information too -- the resulting capacity request might be above the
CPU capacity if p's util_avg is large, so we should probably skip the
CPU too no ?

Are we gaining anything if we decide to not align the EAS path and the
sugov path ?

Thanks,
Quentin
\
 
 \ /
  Last update: 2019-11-21 16:31    [W:0.055 / U:6.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site