Messages in this thread | | | Date | Tue, 18 Jun 2019 09:22:12 +0100 | From | Quentin Perret <> | Subject | Re: [PATCH] sched/fair: Introduce fits_capacity() |
| |
On Tuesday 18 Jun 2019 at 13:17:28 (+0530), Viresh Kumar wrote: > On 18-06-19, 09:26, Rafael J. Wysocki wrote: > > On Tue, Jun 18, 2019 at 5:12 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > > > > > +Rafael > > > > > > On 17-06-19, 17:02, Peter Zijlstra wrote: > > > > On Thu, Jun 06, 2019 at 08:22:04AM +0530, Viresh Kumar wrote: > > > > > Hmm, even if the values are same currently I am not sure if we want > > > > > the same for ever. I will write a patch for it though, if Peter/Rafael > > > > > feel the same as you. > > > > > > > > Is it really the same variable or just two numbers that happen to be the > > > > same? > > > > > > In both cases we are trying to keep the load under 80% of what can be supported. > > > But I am not sure of the answer to your question. > > > > > > Maybe Rafael knows :) > > > > Which variable? > > Schedutil multiplies the target frequency by 1.25 (20% more capacity eventually) > to get enough room for more load and similar thing is done in fair.c at several > places to see if the new task can fit in a runqueue without overloading it. > > Quentin suggested to use common code for this calculation and that is what is > getting discussed here.
Right, sugov and load balance happen to use the same margin (1.25) to check if a given util fits in a given capacity, though the thresholds are hardcoded in different places (see map_util_freq() and capacity_margin). So my suggestion was to unify the capacity_margin code for frequency selection and CPU selection, for clarity and consistency.
But again, this is a small thing and FWIW Viresh's patch LGTM as-is so no objection from my end if you guys would like to merge it.
Thanks, Quentin
| |