On Fri, 22 Jun 2018 at 17:23, Peter Zijlstra wrote:
>
> On Fri, Jun 22, 2018 at 01:37:13PM +0200, Peter Zijlstra wrote:
> > That is true.. So we could limit the scaling to the case where there is
> > no idle time, something like:
> >
> > util = sg_cpu->util_cfs;
> >
> > cap_cfs = (1024
On Friday 22 Jun 2018 at 17:22:58 (+0200), Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 01:37:13PM +0200, Peter Zijlstra wrote:
> > That is true.. So we could limit the scaling to the case where there is
> > no idle time, something like:
> >
> > util = sg_cpu->util_cfs;
> >
> > cap_cfs
On Fri, Jun 22, 2018 at 01:37:13PM +0200, Peter Zijlstra wrote:
> That is true.. So we could limit the scaling to the case where there is
> no idle time, something like:
>
> util = sg_cpu->util_cfs;
>
> cap_cfs = (1024 - (sg_cpu->util_rt + ...));
> if (util == cap_cfs)
>
On Fri, 22 Jun 2018 at 16:46, Peter Zijlstra wrote:
>
> On Fri, Jun 22, 2018 at 03:57:24PM +0200, Vincent Guittot wrote:
> > On Fri, 22 Jun 2018 at 15:54, Vincent Guittot
> > wrote:
> > > On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra wrote:
>
> > > > And that is my objection to that straight sum
On Fri, Jun 22, 2018 at 04:11:59PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 03:54:24PM +0200, Vincent Guittot wrote:
> > On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra wrote:
>
> > > define f (u,r,n) { return u + ((u/(1-r)) - u) * (u/(1-r))^n; }
> > I'm a bit lost with your example.
On Fri, Jun 22, 2018 at 03:57:24PM +0200, Vincent Guittot wrote:
> On Fri, 22 Jun 2018 at 15:54, Vincent Guittot
> wrote:
> > On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra wrote:
> > > And that is my objection to that straight sum thing; there the dl util
> > > distorts the computed dl bandwidth
On Fri, 22 Jun 2018 at 15:54, Vincent Guittot
wrote:
>
> On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra wrote:
> >
> > On Fri, Jun 22, 2018 at 02:23:22PM +0200, Vincent Guittot wrote:
> > > On Fri, 22 Jun 2018 at 13:37, Peter Zijlstra wrote:
> > > > I suppose we can make it more complicated, somet
On Fri, Jun 22, 2018 at 03:54:24PM +0200, Vincent Guittot wrote:
> On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra wrote:
> > $ bc -l
> > define f (u,r,n) { return u + ((u/(1-r)) - u) * (u/(1-r))^n; }
> > f(.2,.7,0)
> > .
> > f(.2,.7,2)
> > .40740740740740740739
> > f(.2,.7,4)
>
On Fri, 22 Jun 2018 at 15:54, Vincent Guittot
wrote:
>
> On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra wrote:
> >
> > On Fri, Jun 22, 2018 at 02:23:22PM +0200, Vincent Guittot wrote:
> > > On Fri, 22 Jun 2018 at 13:37, Peter Zijlstra wrote:
> > > > I suppose we can make it more complicated, somet
On Fri, 22 Jun 2018 at 15:26, Peter Zijlstra wrote:
>
> On Fri, Jun 22, 2018 at 02:23:22PM +0200, Vincent Guittot wrote:
> > On Fri, 22 Jun 2018 at 13:37, Peter Zijlstra wrote:
> > > I suppose we can make it more complicated, something like:
> > >
> > > u u
> > > f := u +
On Fri, Jun 22, 2018 at 03:26:24PM +0200, Peter Zijlstra wrote:
> > But this also means that we will start to inflate the utilization to
> > get higher OPP even if there is idle time and lost the interest of
> > using dl bw
>
> You get _some_ inflation, but only if there is actual cfs utilization
On Fri, Jun 22, 2018 at 01:54:34PM +0100, Quentin Perret wrote:
> On Friday 22 Jun 2018 at 13:37:13 (+0200), Peter Zijlstra wrote:
> > That is true.. So we could limit the scaling to the case where there is
> > no idle time, something like:
> >
> > util = sg_cpu->util_cfs;
> >
> > cap_cfs
On Fri, Jun 22, 2018 at 02:23:22PM +0200, Vincent Guittot wrote:
> On Fri, 22 Jun 2018 at 13:37, Peter Zijlstra wrote:
> > I suppose we can make it more complicated, something like:
> >
> > u u
> > f := u + (--- - u) * (---)^n
> > 1-r 1-r
> >
> > Where:
On Friday 22 Jun 2018 at 13:37:13 (+0200), Peter Zijlstra wrote:
> That is true.. So we could limit the scaling to the case where there is
> no idle time, something like:
>
> util = sg_cpu->util_cfs;
>
> cap_cfs = (1024 - (sg_cpu->util_rt + ...));
> if (util == cap_cfs)
>
On Fri, 22 Jun 2018 at 13:37, Peter Zijlstra wrote:
>
> On Fri, Jun 22, 2018 at 08:58:53AM +0100, Quentin Perret wrote:
> > Say we have 50% of the capacity stolen by RT, and a 25% CFS task
> > running. If we re-scale, we'll end up with a 50% request for CFS
> > (util==512 for your code above). But
On Fri, 22 Jun 2018 at 13:41, Peter Zijlstra wrote:
>
> On Fri, Jun 22, 2018 at 10:10:32AM +0200, Vincent Guittot wrote:
> > On Thu, 21 Jun 2018 at 20:57, Peter Zijlstra wrote:
> > >
> > > > So this (and the dl etc. equivalents) result in exactly the problems
> > > > complained about last time, n
On Fri, Jun 22, 2018 at 01:37:13PM +0200, Peter Zijlstra wrote:
> I suppose we can make it more complicated, something like:
>
> u u
> f := u + (--- - u) * (---)^n
> 1-r 1-r
>
> Where: u := cfs util
>r := \Sum !cfs util
>f := frequency
On Fri, Jun 22, 2018 at 10:10:32AM +0200, Vincent Guittot wrote:
> On Thu, 21 Jun 2018 at 20:57, Peter Zijlstra wrote:
> >
> > > So this (and the dl etc. equivalents) result in exactly the problems
> > > complained about last time, no?
> > >
> > > What I proposed was something along the lines of:
On Fri, Jun 22, 2018 at 08:58:53AM +0100, Quentin Perret wrote:
> Say we have 50% of the capacity stolen by RT, and a 25% CFS task
> running. If we re-scale, we'll end up with a 50% request for CFS
> (util==512 for your code above). But if we want to see a little bit
> of idle time in the system, w
On Thu, 21 Jun 2018 at 20:57, Peter Zijlstra wrote:
>
> On Thu, Jun 21, 2018 at 08:45:24PM +0200, Peter Zijlstra wrote:
> > On Fri, Jun 08, 2018 at 02:09:47PM +0200, Vincent Guittot wrote:
> > > static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
> > > {
> > > struct rq *rq =
On 21/06/18 20:45, Peter Zijlstra wrote:
> On Fri, Jun 08, 2018 at 02:09:47PM +0200, Vincent Guittot wrote:
> > static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
> > {
> > struct rq *rq = cpu_rq(sg_cpu->cpu);
> > + unsigned long util;
> >
> > if (rq->rt.rt_nr_running
Hi Peter,
On Thursday 21 Jun 2018 at 20:45:24 (+0200), Peter Zijlstra wrote:
> On Fri, Jun 08, 2018 at 02:09:47PM +0200, Vincent Guittot wrote:
> > static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
> > {
> > struct rq *rq = cpu_rq(sg_cpu->cpu);
> > + unsigned long util;
>
On Thu, Jun 21, 2018 at 08:45:24PM +0200, Peter Zijlstra wrote:
> On Fri, Jun 08, 2018 at 02:09:47PM +0200, Vincent Guittot wrote:
> > static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
> > {
> > struct rq *rq = cpu_rq(sg_cpu->cpu);
> > + unsigned long util;
> >
> > i
On Fri, Jun 08, 2018 at 02:09:47PM +0200, Vincent Guittot wrote:
> static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
> {
> struct rq *rq = cpu_rq(sg_cpu->cpu);
> + unsigned long util;
>
> if (rq->rt.rt_nr_running)
> return sg_cpu->max;
>
> +
On Mon, 18 Jun 2018 at 11:00, Dietmar Eggemann wrote:
>
> On 06/08/2018 02:09 PM, Vincent Guittot wrote:
> > Take into account rt utilization when selecting an OPP for cfs tasks in
> > order
> > to reflect the utilization of the CPU.
>
> The rt utilization signal is only tracked per-cpu, not per-
On 06/08/2018 02:09 PM, Vincent Guittot wrote:
Take into account rt utilization when selecting an OPP for cfs tasks in order
to reflect the utilization of the CPU.
The rt utilization signal is only tracked per-cpu, not per-entity. So it
is not aware of PELT migrations (attach/detach).
IMHO,
Take into account rt utilization when selecting an OPP for cfs tasks in order
to reflect the utilization of the CPU.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Vincent Guittot
---
kernel/sched/cpufreq_schedutil.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git
27 matches
Mail list logo