Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20/12/17 15:47, Rafael J. Wysocki wrote: > On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote: > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > > > Didn't juri have patches to make DL do something sane?

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

On 20/12/17 15:47, Rafael J. Wysocki wrote: > On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote: > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote: > > > On 20-Dec 09:31, Peter Zijlstra wrote: > > > > > > Didn't juri have patches to make DL do something sane?

Re: [PATCH 4/4] cpufreq: schedutil: Don't call sugov_get_util() unnecessarily

Hi, On 13/12/17 15:23, Viresh Kumar wrote: > sugov_update_shared() may get called to clear the scheduling class flags > and we would return immediately in that case. Calling sugov_get_util() > in that case isn't going to be of any use then. Move invocation of > sugov_get_util() after the clear

Re: [PATCH 4/4] cpufreq: schedutil: Don't call sugov_get_util() unnecessarily

Hi, On 13/12/17 15:23, Viresh Kumar wrote: > sugov_update_shared() may get called to clear the scheduling class flags > and we would return immediately in that case. Calling sugov_get_util() > in that case isn't going to be of any use then. Move invocation of > sugov_get_util() after the clear

Re: [PATCH 3/4] cpufreq: schedutil: Don't pass flags to sugov_set_iowait_boost()

Hi, On 13/12/17 15:23, Viresh Kumar wrote: > We are already passing sg_cpu as argument to sugov_set_iowait_boost() > helper and the same can be used to retrieve the flags value. Get rid of > the redundant argument. > > Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org&g

Re: [PATCH 3/4] cpufreq: schedutil: Don't pass flags to sugov_set_iowait_boost()

Hi, On 13/12/17 15:23, Viresh Kumar wrote: > We are already passing sg_cpu as argument to sugov_set_iowait_boost() > helper and the same can be used to retrieve the flags value. Get rid of > the redundant argument. > > Signed-off-by: Viresh Kumar Reviewed-by: Juri Lelli Best, - Juri

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

ine SCHED_CPUFREQ_IOWAIT (1U << 2) > +#define SCHED_CPUFREQ_CFS(1U << 2) This flag doesn't do much, does it? I mean RT/DL/IOWAIT are used to bump up frequency, while you are adding CFS for the sake of simmetry, right? And with my patches DL will hopefully soon be in the same sit

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

2) > +#define SCHED_CPUFREQ_CFS(1U << 2) This flag doesn't do much, does it? I mean RT/DL/IOWAIT are used to bump up frequency, while you are adding CFS for the sake of simmetry, right? And with my patches DL will hopefully soon be in the same situation. If my understanding is correct, maybe add a comment? Apart from this, patch looks good to me; couldn't test it though, sorry. Reviewed-by: Juri Lelli Thanks, - Juri

Re: [PATCH 1/4] cpufreq: schedutil: Initialize sg_cpu->flags to 0

t; flags anyway. > > Initialize it to 0. > > Change-Id: I028dbb40c5c242cff52fe1b14aeaff37f29a2f8d Without ^ > Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> Reviewed-by: Juri Lelli <juri.le...@redhat.com> Best, - Juri

Re: [PATCH 1/4] cpufreq: schedutil: Initialize sg_cpu->flags to 0

t; flags anyway. > > Initialize it to 0. > > Change-Id: I028dbb40c5c242cff52fe1b14aeaff37f29a2f8d Without ^ > Signed-off-by: Viresh Kumar Reviewed-by: Juri Lelli Best, - Juri

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On 12/12/17 20:10, Viresh Kumar wrote: > On 12-12-17, 14:38, Juri Lelli wrote: > > Hi Viresh, > > > > On 12/12/17 17:07, Viresh Kumar wrote: > > > > [...] > > > > > From: Viresh Kumar <viresh.ku...@linaro.org> > > > Date: Tue, 12 D

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On 12/12/17 20:10, Viresh Kumar wrote: > On 12-12-17, 14:38, Juri Lelli wrote: > > Hi Viresh, > > > > On 12/12/17 17:07, Viresh Kumar wrote: > > > > [...] > > > > > From: Viresh Kumar > > > Date: Tue, 12 Dec 2017 15:43:26 +0530 > &

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

Hi Viresh, On 12/12/17 17:07, Viresh Kumar wrote: [...] > From: Viresh Kumar > Date: Tue, 12 Dec 2017 15:43:26 +0530 > Subject: [PATCH] sched: Keep track of cpufreq utilization update flags > > Currently the schedutil governor overwrites the sg_cpu->flags field on >

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

Hi Viresh, On 12/12/17 17:07, Viresh Kumar wrote: [...] > From: Viresh Kumar > Date: Tue, 12 Dec 2017 15:43:26 +0530 > Subject: [PATCH] sched: Keep track of cpufreq utilization update flags > > Currently the schedutil governor overwrites the sg_cpu->flags field on > every call to the

Re: [RFC PATCH v2 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal

On 05/12/17 16:34, Patrick Bellasi wrote: > On 05-Dec 16:24, Juri Lelli wrote: > > On 05/12/17 15:09, Patrick Bellasi wrote: > > > > + /* > > > > +* Ideally we would like to set util_dl as min/guaranteed freq > > > > and > >

Re: [RFC PATCH v2 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal

On 05/12/17 16:34, Patrick Bellasi wrote: > On 05-Dec 16:24, Juri Lelli wrote: > > On 05/12/17 15:09, Patrick Bellasi wrote: > > > > + /* > > > > +* Ideally we would like to set util_dl as min/guaranteed freq > > > > and > >

Re: [RFC PATCH v2 4/8] sched/cpufreq_schedutil: split utilization signals

Hi, On 05/12/17 15:17, Patrick Bellasi wrote: > Hi Juri, > > On 04-Dec 11:23, Juri Lelli wrote: > > From: Juri Lelli <juri.le...@arm.com> > > > > To be able to treat utilization signals of different scheduling classes > > in different ways (e.g., CFS sign

Re: [RFC PATCH v2 4/8] sched/cpufreq_schedutil: split utilization signals

Hi, On 05/12/17 15:17, Patrick Bellasi wrote: > Hi Juri, > > On 04-Dec 11:23, Juri Lelli wrote: > > From: Juri Lelli > > > > To be able to treat utilization signals of different scheduling classes > > in different ways (e.g., CFS signal might be stale while D

Re: [RFC PATCH v2 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal

Hi, On 05/12/17 15:09, Patrick Bellasi wrote: > Hi Juri, > [...] > > static void sugov_get_util(unsigned long *util, unsigned long *max, int > > cpu) > > { > > struct rq *rq = cpu_rq(cpu); > > - unsigned long cfs_max; > > + unsigned long dl_util = (rq->dl.running_bw *

Re: [RFC PATCH v2 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal

Hi, On 05/12/17 15:09, Patrick Bellasi wrote: > Hi Juri, > [...] > > static void sugov_get_util(unsigned long *util, unsigned long *max, int > > cpu) > > { > > struct rq *rq = cpu_rq(cpu); > > - unsigned long cfs_max; > > + unsigned long dl_util = (rq->dl.running_bw *

Re: [RFC PATCH v2 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

Hi, On 05/12/17 11:55, Patrick Bellasi wrote: > Hi Juri, > > On 04-Dec 11:23, Juri Lelli wrote: > [...] > > > diff --git a/kernel/sched/cpufreq_schedutil.c > > b/kernel/sched/cpufreq_schedutil.c > > index de1ad1fffbdc..c22457868ee6 100644 > > --- a/ker

Re: [RFC PATCH v2 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

Hi, On 05/12/17 11:55, Patrick Bellasi wrote: > Hi Juri, > > On 04-Dec 11:23, Juri Lelli wrote: > [...] > > > diff --git a/kernel/sched/cpufreq_schedutil.c > > b/kernel/sched/cpufreq_schedutil.c > > index de1ad1fffbdc..c22457868ee6 100644 > > --- a/ker

[RFC PATCH v2 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal

From: Juri Lelli <juri.le...@arm.com> SCHED_DEADLINE tracks active utilization signal with a per dl_rq variable named running_bw. Make use of that to drive cpu frequency selection: add up FAIR and DEADLINE contribution to get the required CPU capacity to handle both requirements (while RT

[RFC PATCH v2 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal

From: Juri Lelli SCHED_DEADLINE tracks active utilization signal with a per dl_rq variable named running_bw. Make use of that to drive cpu frequency selection: add up FAIR and DEADLINE contribution to get the required CPU capacity to handle both requirements (while RT still selects max

[RFC PATCH v2 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

From: Juri Lelli <juri.le...@arm.com> Worker kthread needs to be able to change frequency for all other threads. Make it special, just under STOP class. Signed-off-by: Juri Lelli <juri.le...@arm.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@ker

[RFC PATCH v2 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

From: Juri Lelli Worker kthread needs to be able to change frequency for all other threads. Make it special, just under STOP class. Signed-off-by: Juri Lelli Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Luca Abeni Cc: Claudio Scordino --- Changes from

[RFC PATCH v2 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

From: Juri Lelli <juri.le...@arm.com> No assumption can be made upon the rate at which frequency updates get triggered, as there are scheduling policies (like SCHED_DEADLINE) which don't trigger them so frequently. Remove such assumption from the code, by always considering SCHED_DE

[RFC PATCH v2 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

From: Juri Lelli No assumption can be made upon the rate at which frequency updates get triggered, as there are scheduling policies (like SCHED_DEADLINE) which don't trigger them so frequently. Remove such assumption from the code, by always considering SCHED_DEADLINE utilization signal

[RFC PATCH v2 7/8] sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP

From: Juri Lelli <juri.le...@arm.com> Currently, frequency and cpu capacity scaling is only performed on CONFIG_SMP systems (as CFS PELT signals are only present for such systems). However, other scheduling classes want to do freq/cpu scaling, and for !CONFIG_SMP configurations a

[RFC PATCH v2 6/8] sched/sched.h: remove sd arch_scale_freq_capacity parameter

From: Juri Lelli <juri.le...@arm.com> sd parameter is never used in arch_scale_freq_capacity (and it's hard to see where information coming from scheduling domains might help doing frequency invariance scaling). Remove it; also in anticipation of moving arch_scale_freq_capacity o

[RFC PATCH v2 7/8] sched/sched.h: move arch_scale_{freq,cpu}_capacity outside CONFIG_SMP

From: Juri Lelli Currently, frequency and cpu capacity scaling is only performed on CONFIG_SMP systems (as CFS PELT signals are only present for such systems). However, other scheduling classes want to do freq/cpu scaling, and for !CONFIG_SMP configurations as well. arch_scale_freq_capacity

[RFC PATCH v2 6/8] sched/sched.h: remove sd arch_scale_freq_capacity parameter

From: Juri Lelli sd parameter is never used in arch_scale_freq_capacity (and it's hard to see where information coming from scheduling domains might help doing frequency invariance scaling). Remove it; also in anticipation of moving arch_scale_freq_capacity outside CONFIG_SMP. Signed-off

[RFC PATCH v2 4/8] sched/cpufreq_schedutil: split utilization signals

From: Juri Lelli <juri.le...@arm.com> To be able to treat utilization signals of different scheduling classes in different ways (e.g., CFS signal might be stale while DEADLINE signal is never stale by design) we need to split sugov_cpu::util signal in two: util_cfs and util_dl. This patc

[RFC PATCH v2 4/8] sched/cpufreq_schedutil: split utilization signals

From: Juri Lelli To be able to treat utilization signals of different scheduling classes in different ways (e.g., CFS signal might be stale while DEADLINE signal is never stale by design) we need to split sugov_cpu::util signal in two: util_cfs and util_dl. This patch does that by also changing

[RFC PATCH v2 8/8] sched/deadline: make bandwidth enforcement scale-invariant

From: Juri Lelli <juri.le...@arm.com> Apply frequency and cpu scale-invariance correction factor to bandwidth enforcement (similar to what we already do to fair utilization tracking). Each delta_exec gets scaled considering current frequency and maximum cpu capacity; which

[RFC PATCH v2 8/8] sched/deadline: make bandwidth enforcement scale-invariant

From: Juri Lelli Apply frequency and cpu scale-invariance correction factor to bandwidth enforcement (similar to what we already do to fair utilization tracking). Each delta_exec gets scaled considering current frequency and maximum cpu capacity; which means that the reservation runtime

[RFC PATCH v2 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

. Scordino, G. Lipari, A Resource Reservation Algorithm for Power-Aware Scheduling of Periodic and Aperiodic Real-Time Tasks, IEEE Transactions on Computers, December 2006 Juri Lelli (8): sched/cpufreq_schedutil: make use of DEADLINE utilization signal sched/deadline: move cpu frequency

[RFC PATCH v2 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

. Scordino, G. Lipari, A Resource Reservation Algorithm for Power-Aware Scheduling of Periodic and Aperiodic Real-Time Tasks, IEEE Transactions on Computers, December 2006 Juri Lelli (8): sched/cpufreq_schedutil: make use of DEADLINE utilization signal sched/deadline: move cpu frequency

[RFC PATCH v2 2/8] sched/deadline: move cpu frequency selection triggering points

From: Juri Lelli <juri.le...@arm.com> Since SCHED_DEADLINE doesn't track utilization signal (but reserves a fraction of CPU bandwidth to tasks admitted to the system), there is no point in evaluating frequency changes during each tick event. Move frequency selection triggering points to

[RFC PATCH v2 2/8] sched/deadline: move cpu frequency selection triggering points

From: Juri Lelli Since SCHED_DEADLINE doesn't track utilization signal (but reserves a fraction of CPU bandwidth to tasks admitted to the system), there is no point in evaluating frequency changes during each tick event. Move frequency selection triggering points to where running_bw changes

Re: [PATCH] sched/rt: Do not pull from current CPU if only one cpu to pull

On 04/12/17 03:09, Steven Rostedt wrote: > On Mon, 4 Dec 2017 08:45:17 +0100 > Juri Lelli <juri.le...@redhat.com> wrote: > > > Right. I was wondering however if for the truly UP case we shouldn't be > > initiating/queueing callbacks (pull/push) at all? > > If !

Re: [PATCH] sched/rt: Do not pull from current CPU if only one cpu to pull

On 04/12/17 03:09, Steven Rostedt wrote: > On Mon, 4 Dec 2017 08:45:17 +0100 > Juri Lelli wrote: > > > Right. I was wondering however if for the truly UP case we shouldn't be > > initiating/queueing callbacks (pull/push) at all? > > If !CONFIG_SMP then it's not com

Re: [PATCH] sched/rt: Do not pull from current CPU if only one cpu to pull

Hi Steve, On 02/12/17 13:04, Steven Rostedt wrote: > Daniel Wagner reported a crash on the beaglebone black. This is a > single CPU architecture, and does not have a functional: > arch_send_call_function_single_ipi() and can crash if that is called. > > As it only has one CPU, it shouldn't be

Re: [PATCH] sched/rt: Do not pull from current CPU if only one cpu to pull

Hi Steve, On 02/12/17 13:04, Steven Rostedt wrote: > Daniel Wagner reported a crash on the beaglebone black. This is a > single CPU architecture, and does not have a functional: > arch_send_call_function_single_ipi() and can crash if that is called. > > As it only has one CPU, it shouldn't be

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On 30/11/17 16:19, Patrick Bellasi wrote: > On 30-Nov 17:02, Juri Lelli wrote: > > On 30/11/17 15:41, Patrick Bellasi wrote: > > > On 30-Nov 14:12, Juri Lelli wrote: > > > > Hi, > > > > > > > > On 30/11/17 11:47, Patrick Bellasi wrote: > &g

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On 30/11/17 16:19, Patrick Bellasi wrote: > On 30-Nov 17:02, Juri Lelli wrote: > > On 30/11/17 15:41, Patrick Bellasi wrote: > > > On 30-Nov 14:12, Juri Lelli wrote: > > > > Hi, > > > > > > > > On 30/11/17 11:47, Patrick Bellasi wrote: > &g

Re: [PATCH v3 6/6] cpufreq: schedutil: ignore sugov kthreads

On 30/11/17 16:02, Patrick Bellasi wrote: > On 30-Nov 14:41, Juri Lelli wrote: [...] > > If the DL changes (which I shall post again as soon as tip/sched/core is > > bumped up to 4.15-rc1) get in first, this is going to be useless (as the > > DL kthread gets ignored by

Re: [PATCH v3 6/6] cpufreq: schedutil: ignore sugov kthreads

On 30/11/17 16:02, Patrick Bellasi wrote: > On 30-Nov 14:41, Juri Lelli wrote: [...] > > If the DL changes (which I shall post again as soon as tip/sched/core is > > bumped up to 4.15-rc1) get in first, this is going to be useless (as the > > DL kthread gets ignored by

Re: [PATCH v3 5/6] cpufreq: schedutil: relax rate-limiting while running RT/DL tasks

On 30/11/17 15:54, Patrick Bellasi wrote: > On 30-Nov 14:36, Juri Lelli wrote: [...] > > I wonder if we would also need some way to trigger a back to back update > > as soon as a currently running one finishes and an RT/DL task asked for > > an update (without wait

Re: [PATCH v3 5/6] cpufreq: schedutil: relax rate-limiting while running RT/DL tasks

On 30/11/17 15:54, Patrick Bellasi wrote: > On 30-Nov 14:36, Juri Lelli wrote: [...] > > I wonder if we would also need some way to trigger a back to back update > > as soon as a currently running one finishes and an RT/DL task asked for > > an update (without wait

Re: [PATCH v3 2/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks

On 30/11/17 15:45, Patrick Bellasi wrote: > On 30-Nov 14:17, Juri Lelli wrote: > > Hi, > > > > On 30/11/17 11:47, Patrick Bellasi wrote: > > > > [...] > > > > > @@ -340,6 +349,7 @@ static void sugov_update_shared(struct > > > upda

Re: [PATCH v3 2/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks

On 30/11/17 15:45, Patrick Bellasi wrote: > On 30-Nov 14:17, Juri Lelli wrote: > > Hi, > > > > On 30/11/17 11:47, Patrick Bellasi wrote: > > > > [...] > > > > > @@ -340,6 +349,7 @@ static void sugov_update_shared(struct > > > upda

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On 30/11/17 15:41, Patrick Bellasi wrote: > On 30-Nov 14:12, Juri Lelli wrote: > > Hi, > > > > On 30/11/17 11:47, Patrick Bellasi wrote: > > > > [...] > > > > > diff --git a/kernel/sched/cpufreq_schedutil.c > > > b/kernel/sched/cpufreq_

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

On 30/11/17 15:41, Patrick Bellasi wrote: > On 30-Nov 14:12, Juri Lelli wrote: > > Hi, > > > > On 30/11/17 11:47, Patrick Bellasi wrote: > > > > [...] > > > > > diff --git a/kernel/sched/cpufreq_schedutil.c > > > b/kernel/sched/cpufreq_

Re: [PATCH v3 6/6] cpufreq: schedutil: ignore sugov kthreads

t; + return; > + > raw_spin_lock(_policy->update_lock); > > sugov_get_util(, , sg_cpu->cpu); If the DL changes (which I shall post again as soon as tip/sched/core is bumped up to 4.15-rc1) get in first, this is going to be useless (as the DL kthread gets ignored by the scheduling class itself). But, this looks good to me "in the meantime". Reviewed-by: Juri Lelli <juri.le...@redhat.com> Best, Juri

Re: [PATCH v3 6/6] cpufreq: schedutil: ignore sugov kthreads

s soon as tip/sched/core is bumped up to 4.15-rc1) get in first, this is going to be useless (as the DL kthread gets ignored by the scheduling class itself). But, this looks good to me "in the meantime". Reviewed-by: Juri Lelli Best, Juri

Re: [PATCH v3 5/6] cpufreq: schedutil: relax rate-limiting while running RT/DL tasks

sugov_cpu_is_busy(sg_cpu); > + > if (rt_mode) { > next_f = policy->cpuinfo.max_freq; > } else { > @@ -379,7 +384,7 @@ static void sugov_update_shared(struct update_util_data > *hook, u64 time, > sugov_set_iowait_boost(sg_cpu, time, flags); > sg_cpu->l

Re: [PATCH v3 5/6] cpufreq: schedutil: relax rate-limiting while running RT/DL tasks

ruct update_util_data > *hook, u64 time, > sugov_set_iowait_boost(sg_cpu, time, flags); > sg_cpu->last_update = time; > > - if (sugov_should_update_freq(sg_policy, time)) { > + if (sugov_should_update_freq(sg_policy, time, rt_mode)) { >

Re: [PATCH v3 4/6] sched/rt: fast switch to maximum frequency when RT tasks are scheduled

PU > - when we actually pick a RT task for execution > - at each tick time > - when a task is set to be RT > > Signed-off-by: Patrick Bellasi <patrick.bell...@arm.com> > Reviewed-by: Dietmar Eggemann <dietmar.eggem...@arm.com> Reviewed-by: Juri Lelli <juri.le...@redhat.com> Best, Juri

Re: [PATCH v3 4/6] sched/rt: fast switch to maximum frequency when RT tasks are scheduled

PU > - when we actually pick a RT task for execution > - at each tick time > - when a task is set to be RT > > Signed-off-by: Patrick Bellasi > Reviewed-by: Dietmar Eggemann Reviewed-by: Juri Lelli Best, Juri

Re: [PATCH v3 3/6] cpufreq: schedutil: update CFS util only if used

ode; > > - sugov_get_util(, , sg_cpu->cpu); > - > raw_spin_lock(_policy->update_lock); > > + sugov_get_util(, , sg_cpu->cpu); > sg_cpu->util = util; > sg_cpu->max = max; Patch looks good. Reviewed-by: Juri Lelli <juri.le...@redhat.

Re: [PATCH v3 3/6] cpufreq: schedutil: update CFS util only if used

void sugov_update_shared(struct update_util_data > *hook, u64 time, > unsigned int next_f; > bool rt_mode; > > - sugov_get_util(, , sg_cpu->cpu); > - > raw_spin_lock(_policy->update_lock); > > + sugov_get_util(, , sg_cpu->cpu); > sg_

Re: [PATCH v3 2/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks

Hi, On 30/11/17 11:47, Patrick Bellasi wrote: [...] > @@ -340,6 +349,7 @@ static void sugov_update_shared(struct update_util_data > *hook, u64 time, > struct sugov_policy *sg_policy = sg_cpu->sg_policy; > unsigned long util, max; > unsigned int next_f; > + bool rt_mode; >

Re: [PATCH v3 2/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks

Hi, On 30/11/17 11:47, Patrick Bellasi wrote: [...] > @@ -340,6 +349,7 @@ static void sugov_update_shared(struct update_util_data > *hook, u64 time, > struct sugov_policy *sg_policy = sg_cpu->sg_policy; > unsigned long util, max; > unsigned int next_f; > + bool rt_mode; >

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

Hi, On 30/11/17 11:47, Patrick Bellasi wrote: [...] > diff --git a/kernel/sched/cpufreq_schedutil.c > b/kernel/sched/cpufreq_schedutil.c > index 2f52ec0f1539..67339ccb5595 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -347,6 +347,12 @@ static

Re: [PATCH v3 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

Hi, On 30/11/17 11:47, Patrick Bellasi wrote: [...] > diff --git a/kernel/sched/cpufreq_schedutil.c > b/kernel/sched/cpufreq_schedutil.c > index 2f52ec0f1539..67339ccb5595 100644 > --- a/kernel/sched/cpufreq_schedutil.c > +++ b/kernel/sched/cpufreq_schedutil.c > @@ -347,6 +347,12 @@ static

[ANNOUNCE][CFP] Power Management and Scheduling in the Linux Kernel II edition (OSPM-summit 2018)

/presentations will be sent out on 23rd of December 2017. .:: ORGANISERS (in alphabetical order) Luca Abeni (SSSA) Patrick Bellasi (Arm) Tommaso Cucinotta (SSSA) Dietmar Eggemann (Arm) Sudeep Holla (Arm) Juri Lelli (Red Hat) Lorenzo Pieralisi (Arm) Morten Rasmussen (Arm) Claudio Scordino (Evidence SRL)

[ANNOUNCE][CFP] Power Management and Scheduling in the Linux Kernel II edition (OSPM-summit 2018)

/presentations will be sent out on 23rd of December 2017. .:: ORGANISERS (in alphabetical order) Luca Abeni (SSSA) Patrick Bellasi (Arm) Tommaso Cucinotta (SSSA) Dietmar Eggemann (Arm) Sudeep Holla (Arm) Juri Lelli (Red Hat) Lorenzo Pieralisi (Arm) Morten Rasmussen (Arm) Claudio Scordino (Evidence SRL)

Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting

Hi, On 24/08/17 09:53, Luca Abeni wrote: > On Wed, 23 Aug 2017 13:47:13 -0600 > Mathieu Poirier wrote: > > >> This is a renewed attempt at fixing a problem reported by Steve Rostedt > > >> [1] > > >> where DL bandwidth accounting is not recomputed after CPUset and >

Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting

Hi, On 24/08/17 09:53, Luca Abeni wrote: > On Wed, 23 Aug 2017 13:47:13 -0600 > Mathieu Poirier wrote: > > >> This is a renewed attempt at fixing a problem reported by Steve Rostedt > > >> [1] > > >> where DL bandwidth accounting is not recomputed after CPUset and > > >> CPUhotplug > > >>

Re: [PATCH v9 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

er choice, since cpu3 is a (SMT) thread of an already loaded core. > + * of cpu3 that is fully loaded. > + * > + * We have to do the best if possible, but choose the second > + * best here since that is too expensive to adopt. > + */ I'd also modify this last paragraph with something like: "Doing it 'right' is difficult and expensive. The current solution is an acceptable approximation." Apart from these minor points, patch looks ok to me. Acked-by: Juri Lelli <juri.le...@arm.com> Best, - Juri

Re: [PATCH v9 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

gt; + * of cpu3 that is fully loaded. > + * > + * We have to do the best if possible, but choose the second > + * best here since that is too expensive to adopt. > + */ I'd also modify this last paragraph with something like: "Doing it 'right' is difficult and expensive. The current solution is an acceptable approximation." Apart from these minor points, patch looks ok to me. Acked-by: Juri Lelli Best, - Juri

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

Hi, On 22/08/17 14:53, Byungchul Park wrote: > On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote: > > Hi, > > On 18/08/17 17:21, Byungchul Park wrote: > > > It would be better to try to check other siblings first if > > > SD_PREFER_SIBLING is flag

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

Hi, On 22/08/17 14:53, Byungchul Park wrote: > On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote: > > Hi, > > On 18/08/17 17:21, Byungchul Park wrote: > > > It would be better to try to check other siblings first if > > > SD_PREFER_SIBLING is flag

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

On 21/08/17 15:56, Peter Zijlstra wrote: > On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote: > > > Also, I'm not sure what Peter meant with > > > > "But still this isn't quite right, because when we consider this for SMT > > (as was the intent here)

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

On 21/08/17 15:56, Peter Zijlstra wrote: > On Mon, Aug 21, 2017 at 02:44:58PM +0100, Juri Lelli wrote: > > > Also, I'm not sure what Peter meant with > > > > "But still this isn't quite right, because when we consider this for SMT > > (as was the intent here)

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

Hi, On 18/08/17 17:21, Byungchul Park wrote: > It would be better to try to check other siblings first if > SD_PREFER_SIBLING is flaged when pushing tasks - migration. > > Signed-off-by: Byungchul Park Mmm, this looks like Peter's proposed patch, maybe add (at least) a

Re: [PATCH v8 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

Hi, On 18/08/17 17:21, Byungchul Park wrote: > It would be better to try to check other siblings first if > SD_PREFER_SIBLING is flaged when pushing tasks - migration. > > Signed-off-by: Byungchul Park Mmm, this looks like Peter's proposed patch, maybe add (at least) a Suggested-by: him ?

Re: [PATCH v3 01/10] drivers base/arch_topology: free cpumask cpus_to_visit

isit is > > only used inside the notifier call init_cpu_capacity_callback. > > > > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> > > Cc: Juri Lelli <juri.le...@arm.com> > > Reported-by: Vincent Guittot <vincent.guit...@linaro.org> > > Signe

Re: [PATCH v3 01/10] drivers base/arch_topology: free cpumask cpus_to_visit

isit is > > only used inside the notifier call init_cpu_capacity_callback. > > > > Cc: Greg Kroah-Hartman > > Cc: Juri Lelli > > Reported-by: Vincent Guittot > > Signed-off-by: Dietmar Eggemann > > Acked-by: Vincent Guittot > > Tested-b

Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks

Hi, On 26/07/17 23:23, Joel Fernandes (Google) wrote: > Hi Viresh, > > On Wed, Jul 26, 2017 at 10:46 PM, Viresh Kumar > wrote: > > On 26-07-17, 22:14, Joel Fernandes (Google) wrote: [...] > > > > But even without that, if you see the routine > >

Re: [Eas-dev] [PATCH V4 0/3] sched: cpufreq: Allow remote callbacks

Hi, On 26/07/17 23:23, Joel Fernandes (Google) wrote: > Hi Viresh, > > On Wed, Jul 26, 2017 at 10:46 PM, Viresh Kumar > wrote: > > On 26-07-17, 22:14, Joel Fernandes (Google) wrote: [...] > > > > But even without that, if you see the routine > > init_entity_runnable_average() in fair.c, the

Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement scale-invariant

On 19/07/17 13:00, Peter Zijlstra wrote: > On Wed, Jul 19, 2017 at 10:20:29AM +0100, Juri Lelli wrote: > > On 19/07/17 09:21, Peter Zijlstra wrote: > > > On Wed, Jul 05, 2017 at 09:59:05AM +0100, Juri Lelli wrote: > > > > @@ -1156,9 +1157,26 @@ static voi

Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement scale-invariant

On 19/07/17 13:00, Peter Zijlstra wrote: > On Wed, Jul 19, 2017 at 10:20:29AM +0100, Juri Lelli wrote: > > On 19/07/17 09:21, Peter Zijlstra wrote: > > > On Wed, Jul 05, 2017 at 09:59:05AM +0100, Juri Lelli wrote: > > > > @@ -1156,9 +1157,26 @@ static voi

Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement scale-invariant

On 19/07/17 09:21, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:05AM +0100, Juri Lelli wrote: > > @@ -1156,9 +1157,26 @@ static void update_curr_dl(struct rq *rq) > > if (unlikely(dl_entity_is_special(dl_se))) > > return; > > > &

Re: [RFC PATCH v1 8/8] sched/deadline: make bandwidth enforcement scale-invariant

On 19/07/17 09:21, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:05AM +0100, Juri Lelli wrote: > > @@ -1156,9 +1157,26 @@ static void update_curr_dl(struct rq *rq) > > if (unlikely(dl_entity_is_special(dl_se))) > > return; > > > &

Re: [PATCH RFC v5] cpufreq: schedutil: Make iowait boost more energy efficient

Hi, On 18/07/17 11:15, Viresh Kumar wrote: > On 17-07-17, 10:35, Joel Fernandes wrote: > > On Mon, Jul 17, 2017 at 1:04 AM, Viresh Kumar > > wrote: > > > On 16-07-17, 01:04, Joel Fernandes wrote: > > > >> + if (sg_cpu->iowait_boost_pending) { > > >> +

Re: [PATCH RFC v5] cpufreq: schedutil: Make iowait boost more energy efficient

Hi, On 18/07/17 11:15, Viresh Kumar wrote: > On 17-07-17, 10:35, Joel Fernandes wrote: > > On Mon, Jul 17, 2017 at 1:04 AM, Viresh Kumar > > wrote: > > > On 16-07-17, 01:04, Joel Fernandes wrote: > > > >> + if (sg_cpu->iowait_boost_pending) { > > >> +

Re: [PATCH] cpufreq: schedutil: Update last_update from sugov_set_iowait_boost()

On 18/07/17 16:55, Viresh Kumar wrote: > On 18-07-17, 12:20, Juri Lelli wrote: > > Hi Viresh, > > > > On 18/07/17 10:24, Viresh Kumar wrote: [...] > > > > It actually belongs here, IMHO. We update other fields (util, max, > > flags) > > Yeah, becau

Re: [PATCH] cpufreq: schedutil: Update last_update from sugov_set_iowait_boost()

On 18/07/17 16:55, Viresh Kumar wrote: > On 18-07-17, 12:20, Juri Lelli wrote: > > Hi Viresh, > > > > On 18/07/17 10:24, Viresh Kumar wrote: [...] > > > > It actually belongs here, IMHO. We update other fields (util, max, > > flags) > > Yeah, becau

Re: [PATCH] cpufreq: schedutil: Update last_update from sugov_set_iowait_boost()

Hi Viresh, On 18/07/17 10:24, Viresh Kumar wrote: > sg_cpu->last_update is always updated right after we call > sugov_set_iowait_boost() and its better to update it from that routine > itself. This makes it more readable. > > Signed-off-by: Viresh Kumar > --- >

Re: [PATCH] cpufreq: schedutil: Update last_update from sugov_set_iowait_boost()

Hi Viresh, On 18/07/17 10:24, Viresh Kumar wrote: > sg_cpu->last_update is always updated right after we call > sugov_set_iowait_boost() and its better to update it from that routine > itself. This makes it more readable. > > Signed-off-by: Viresh Kumar > --- > kernel/sched/cpufreq_schedutil.c

Re: [PATCH v5 2/4] sched/deadline: Change return value of cpudl_find()

Hi, On 23/05/17 11:00, Byungchul Park wrote: > Currently cpudl_find() returns the best cpu that means it has the > maximum dl, however, the value is already kept in later_mask and the > return value is not referred directly any more. > > Now, it's enough to return whether CPUs were found or not,

Re: [PATCH v5 2/4] sched/deadline: Change return value of cpudl_find()

Hi, On 23/05/17 11:00, Byungchul Park wrote: > Currently cpudl_find() returns the best cpu that means it has the > maximum dl, however, the value is already kept in later_mask and the > return value is not referred directly any more. > > Now, it's enough to return whether CPUs were found or not,

Re: [PATCH v5 1/4] sched/deadline: Make find_later_rq() choose a closer cpu in topology

Hi, On 23/05/17 11:00, Byungchul Park wrote: > When cpudl_find() returns any among free_cpus, the cpu might not be > closer than others, considering sched domain. For example: > >this_cpu: 15 >free_cpus: 0, 1,..., 14 (== later_mask) >best_cpu: 0 > >topology: > >0 --+ >

Re: [PATCH v5 1/4] sched/deadline: Make find_later_rq() choose a closer cpu in topology

Hi, On 23/05/17 11:00, Byungchul Park wrote: > When cpudl_find() returns any among free_cpus, the cpu might not be > closer than others, considering sched domain. For example: > >this_cpu: 15 >free_cpus: 0, 1,..., 14 (== later_mask) >best_cpu: 0 > >topology: > >0 --+ >

Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

On 11/07/17 18:17, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:02AM +0100, Juri Lelli wrote: > > delta_ns = time - j_sg_cpu->last_update; > > if (delta_ns > TICK_NSEC) { > > j_sg_cpu->iowait_boost = 0; &g

Re: [RFC PATCH v1 5/8] sched/cpufreq_schedutil: always consider all CPUs when deciding next freq

On 11/07/17 18:17, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:02AM +0100, Juri Lelli wrote: > > delta_ns = time - j_sg_cpu->last_update; > > if (delta_ns > TICK_NSEC) { > > j_sg_cpu->iowait_boost = 0; &g

Re: [RFC PATCH v1 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On 11/07/17 18:18, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:00AM +0100, Juri Lelli wrote: > > @@ -4065,6 +4067,9 @@ static int __sched_setscheduler(struct task_struct *p, > > } > > > > if (user) { > > + if (attr-

Re: [RFC PATCH v1 3/8] sched/cpufreq_schedutil: make worker kthread be SCHED_DEADLINE

On 11/07/17 18:18, Peter Zijlstra wrote: > On Wed, Jul 05, 2017 at 09:59:00AM +0100, Juri Lelli wrote: > > @@ -4065,6 +4067,9 @@ static int __sched_setscheduler(struct task_struct *p, > > } > > > > if (user) { > > + if (attr-

<    3   4   5   6   7   8   9   10   11   12   >