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

On 11/07/17 07:33, Joel Fernandes wrote: > Hi Juri, > > On Tue, Jul 11, 2017 at 12:14 AM, Juri Lelli <juri.le...@arm.com> wrote: > [..] > >> > Considering it a per-cpu thing, isn't enough that it gets bumped up or > >> > decayed only when a C

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

On 11/07/17 07:33, Joel Fernandes wrote: > Hi Juri, > > On Tue, Jul 11, 2017 at 12:14 AM, Juri Lelli wrote: > [..] > >> > Considering it a per-cpu thing, isn't enough that it gets bumped up or > >> > decayed only when a CPU does an update (by using the a

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

On 10/07/17 22:12, Joel Fernandes wrote: > Hi Juri, > > On Mon, Jul 10, 2017 at 3:55 AM, Juri Lelli <juri.le...@arm.com> wrote: > > Hi Joel, > > > > On 09/07/17 10:08, Joel Fernandes wrote: [...] > >> static void sugov_iowait_boost(struct su

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

On 10/07/17 22:12, Joel Fernandes wrote: > Hi Juri, > > On Mon, Jul 10, 2017 at 3:55 AM, Juri Lelli wrote: > > Hi Joel, > > > > On 09/07/17 10:08, Joel Fernandes wrote: [...] > >> static void sugov_iowait_boost(struct sugov_cp

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

Hi Joel, On 09/07/17 10:08, Joel Fernandes wrote: > Currently the iowait_boost feature in schedutil makes the frequency go to max. > This feature was added to handle a case that Peter described where the > throughput of operations involving continuous I/O requests [1] is reduced due > to running

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

Hi Joel, On 09/07/17 10:08, Joel Fernandes wrote: > Currently the iowait_boost feature in schedutil makes the frequency go to max. > This feature was added to handle a case that Peter described where the > throughput of operations involving continuous I/O requests [1] is reduced due > to running

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

Hi, On 07/07/17 14:28, Viresh Kumar wrote: > On 05-07-17, 09:59, Juri Lelli wrote: > > 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 ne

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

Hi, On 07/07/17 14:28, Viresh Kumar wrote: > On 05-07-17, 09:59, Juri Lelli wrote: > > 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 ne

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

On 07/07/17 12:46, Thomas Gleixner wrote: > On Fri, 7 Jul 2017, Juri Lelli wrote: > > How about SCHED_FLAG_SUGOV then? > > I know sugo della carne, but what's sugo V? > Right.. can't really help not thinking about the same (especially close to lunch) :) But the a

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

On 07/07/17 12:46, Thomas Gleixner wrote: > On Fri, 7 Jul 2017, Juri Lelli wrote: > > How about SCHED_FLAG_SUGOV then? > > I know sugo della carne, but what's sugo V? > Right.. can't really help not thinking about the same (especially close to lunch) :) But the a

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

Hi, On 06/07/17 20:56, Joel Fernandes wrote: > Hi Juri, > > On Wed, Jul 5, 2017 at 1:59 AM, Juri Lelli <juri.le...@arm.com> wrote: [...] > > if (attr->sched_flags & > > - ~(SCHED_FLAG_RESET_ON_FORK | SCHED_FLAG_RECLAIM)) > > +

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

Hi, On 06/07/17 20:56, Joel Fernandes wrote: > Hi Juri, > > On Wed, Jul 5, 2017 at 1:59 AM, Juri Lelli wrote: [...] > > if (attr->sched_flags & > > - ~(SCHED_FLAG_RESET_ON_FORK | SCHED_FLAG_RECLAIM)) > > +

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

On 06/07/17 21:43, Joel Fernandes wrote: > On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi > wrote: [...] > > @@ -304,6 +304,12 @@ static void sugov_update_shared(struct > > update_util_data *hook, u64 time, > > > > sg_cpu->util = util; > > sg_cpu->max

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

On 06/07/17 21:43, Joel Fernandes wrote: > On Tue, Jul 4, 2017 at 10:34 AM, Patrick Bellasi > wrote: [...] > > @@ -304,6 +304,12 @@ static void sugov_update_shared(struct > > update_util_data *hook, u64 time, > > > > sg_cpu->util = util; > > sg_cpu->max = max; > > + > > +

Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

On 06/07/17 11:57, Steven Rostedt wrote: > On Wed, 5 Jul 2017 09:58:57 +0100 > Juri Lelli <juri.le...@arm.com> wrote: > > > Hi, > > > > v1 of the RFC set implementing frequency/cpu invariance and OPP selection > > for > > It would be nice if you

Re: [RFC PATCH v1 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

On 06/07/17 11:57, Steven Rostedt wrote: > On Wed, 5 Jul 2017 09:58:57 +0100 > Juri Lelli wrote: > > > Hi, > > > > v1 of the RFC set implementing frequency/cpu invariance and OPP selection > > for > > It would be nice if you specify what "OPP"

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

Hi Viresh, On 06/07/17 15:52, Viresh Kumar wrote: > On 06-07-17, 10:49, Dietmar Eggemann wrote: [...] > > static void parsing_done_workfn(struct work_struct *work) > > { > > + free_cpumask_var(cpus_to_visit); > > cpufreq_unregister_notifier(_cpu_capacity_notifier, > >

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

Hi Viresh, On 06/07/17 15:52, Viresh Kumar wrote: > On 06-07-17, 10:49, Dietmar Eggemann wrote: [...] > > static void parsing_done_workfn(struct work_struct *work) > > { > > + free_cpumask_var(cpus_to_visit); > > cpufreq_unregister_notifier(_cpu_capacity_notifier, > >

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

() parameter list. After this change, aggregation of the different signals has to be performed by sugov_get_util() users (so that they can decide what to do with the different signals). Suggested-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Signed-off-by: Juri Lelli <juri.le...@arm.com&g

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

to be specified profiling the task execution at max frequency on biggest capacity core) gets thus scaled accordingly. Signed-off-by: Juri Lelli <juri.le...@arm.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@kernel.org> Cc: Rafael J. Wysocki <rafael.j.wyso...@

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

() parameter list. After this change, aggregation of the different signals has to be performed by sugov_get_util() users (so that they can decide what to do with the different signals). Suggested-by: Rafael J. Wysocki Signed-off-by: Juri Lelli Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Rafael J

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

to be specified profiling the task execution at max frequency on biggest capacity core) gets thus scaled accordingly. Signed-off-by: Juri Lelli Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Luca Abeni Cc: Claudio Scordino --- kernel/sched/deadline.c | 26

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

invariance. Signed-off-by: Juri Lelli <juri.le...@arm.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@kernel.org> --- include/linux/sched/topology.h | 12 ++-- kernel/sched/sched.h | 13 ++--- 2 files changed, 16 insertions(+), 9 deleti

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

ave a look. Feedback and comments are, as usual, more than welcome. In case you would like to test this out: git://linux-arm.org/linux-jl.git upstream/deadline/freq-rfc-v1 Best, - Juri Juri Lelli (8): sched/cpufreq_schedutil: make use of DEADLINE utilization signal sched/deadline: move cpu

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

invariance. Signed-off-by: Juri Lelli Cc: Peter Zijlstra Cc: Ingo Molnar --- include/linux/sched/topology.h | 12 ++-- kernel/sched/sched.h | 13 ++--- 2 files changed, 16 insertions(+), 9 deletions(-) diff --git a/include/linux/sched/topology.h b/include/linux/sched

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

ave a look. Feedback and comments are, as usual, more than welcome. In case you would like to test this out: git://linux-arm.org/linux-jl.git upstream/deadline/freq-rfc-v1 Best, - Juri Juri Lelli (8): sched/cpufreq_schedutil: make use of DEADLINE utilization signal sched/deadline: move cpu

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

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-by: Juri Lelli <juri

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

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-by: Juri Lelli Cc

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

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...@kernel.org> Cc: Rafael J. Wysocki <rafael.j.

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

-by: Claudio Scordino <clau...@evidence.eu.com> Signed-off-by: Juri Lelli <juri.le...@arm.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@kernel.org> Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Cc: Viresh Kumar <viresh.ku...@linaro.org> Cc: Lu

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

-by: Claudio Scordino <clau...@evidence.eu.com> Signed-off-by: Juri Lelli <juri.le...@arm.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@kernel.org> Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Cc: Viresh Kumar <viresh.ku...@li

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

-by: Juri Lelli <juri.le...@arm.com> Cc: Peter Zijlstra <pet...@infradead.org> Cc: Ingo Molnar <mi...@kernel.org> Cc: Rafael J. Wysocki <rafael.j.wyso...@intel.com> Cc: Viresh Kumar <viresh.ku...@linaro.org> Cc: Luca Abeni <luca.ab...@santannapisa.it> Cc: Claud

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

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 RFCv0: - use a high

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

-by: Claudio Scordino Signed-off-by: Juri Lelli Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Luca Abeni --- Changes from RFCv0: - modify comment regarding periodic RT updates (Claudio) --- kernel/sched/deadline.c | 7 --- kernel/sched/sched.h| 12

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

-by: Claudio Scordino Signed-off-by: Juri Lelli Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Luca Abeni --- Changes from RFCv0: - use BW_SHIFT (Peter) - add comment about guaranteed and requested freq (Peter) - modify comment about go to max behaviour

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

-by: Juri Lelli Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Rafael J. Wysocki Cc: Viresh Kumar Cc: Luca Abeni Cc: Claudio Scordino --- kernel/sched/cpufreq_schedutil.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel

Re: [PATCH] sched/deadline: add GRUB bw change tracepoints

Hi Claudio, On 04/07/17 14:29, Claudio Scordino wrote: > This patch adds a tracepoint for tracing the total and running > bandwidths of GRUB's runqueue. > > Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> > Signed-off-by: Juri Lelli <juri.le...@arm.com> Don'

Re: [PATCH] sched/deadline: add GRUB bw change tracepoints

Hi Claudio, On 04/07/17 14:29, Claudio Scordino wrote: > This patch adds a tracepoint for tracing the total and running > bandwidths of GRUB's runqueue. > > Signed-off-by: Claudio Scordino > Signed-off-by: Juri Lelli Don't remember signing this off. Or if I did it was may

Re: [PATCH V3 0/5] arch_topology: Minor cleanups

setting following in cpu nodes in DT: > capacity-dmips-mhz = <1000>; > The set looks ok to me. Also tested on JunoR2 and TC2. You can add my Reviewed-and-tested-by: Juri Lelli <juri.le...@arm.com> Best, - Juri

Re: [PATCH V3 0/5] arch_topology: Minor cleanups

setting following in cpu nodes in DT: > capacity-dmips-mhz = <1000>; > The set looks ok to me. Also tested on JunoR2 and TC2. You can add my Reviewed-and-tested-by: Juri Lelli Best, - Juri

Re: [PATCH V2 1/5] arch_topology: Get rid of "cap_parsing_done"

On 22/06/17 19:59, Viresh Kumar wrote: > On 22-06-17, 10:44, Juri Lelli wrote: > > Hi, > > > > On 21/06/17 10:16, Viresh Kumar wrote: > > > We can reuse "cap_parsing_failed" instead of keeping an additional > > > variable here. > > >

Re: [PATCH V2 1/5] arch_topology: Get rid of "cap_parsing_done"

On 22/06/17 19:59, Viresh Kumar wrote: > On 22-06-17, 10:44, Juri Lelli wrote: > > Hi, > > > > On 21/06/17 10:16, Viresh Kumar wrote: > > > We can reuse "cap_parsing_failed" instead of keeping an additional > > > variable here. > > > &

Re: [PATCH V2 4/5] arch_topology: Return 0 or -ve errors from topology_parse_cpu_capacity()

On 22/06/17 19:58, Viresh Kumar wrote: > On 22-06-17, 10:39, Juri Lelli wrote: > > Hi, > > > > On 21/06/17 10:16, Viresh Kumar wrote: > > > Use the standard way of returning errors instead of returning 0(failure) > > > OR 1(success) and making it hard to r

Re: [PATCH V2 4/5] arch_topology: Return 0 or -ve errors from topology_parse_cpu_capacity()

On 22/06/17 19:58, Viresh Kumar wrote: > On 22-06-17, 10:39, Juri Lelli wrote: > > Hi, > > > > On 21/06/17 10:16, Viresh Kumar wrote: > > > Use the standard way of returning errors instead of returning 0(failure) > > > OR 1(success) and making it hard to r

Re: [PATCH V2 1/5] arch_topology: Get rid of "cap_parsing_done"

Hi, On 21/06/17 10:16, Viresh Kumar wrote: > We can reuse "cap_parsing_failed" instead of keeping an additional > variable here. > > Signed-off-by: Viresh Kumar > --- > drivers/base/arch_topology.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff

Re: [PATCH V2 1/5] arch_topology: Get rid of "cap_parsing_done"

Hi, On 21/06/17 10:16, Viresh Kumar wrote: > We can reuse "cap_parsing_failed" instead of keeping an additional > variable here. > > Signed-off-by: Viresh Kumar > --- > drivers/base/arch_topology.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git

Re: [PATCH V2 4/5] arch_topology: Return 0 or -ve errors from topology_parse_cpu_capacity()

Hi, On 21/06/17 10:16, Viresh Kumar wrote: > Use the standard way of returning errors instead of returning 0(failure) > OR 1(success) and making it hard to read. > > Signed-off-by: Viresh Kumar > --- > arch/arm/kernel/topology.c | 2 +- > drivers/base/arch_topology.c

Re: [PATCH V2 4/5] arch_topology: Return 0 or -ve errors from topology_parse_cpu_capacity()

Hi, On 21/06/17 10:16, Viresh Kumar wrote: > Use the standard way of returning errors instead of returning 0(failure) > OR 1(success) and making it hard to read. > > Signed-off-by: Viresh Kumar > --- > arch/arm/kernel/topology.c | 2 +- > drivers/base/arch_topology.c | 8 > 2 files

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

Hi, On 14/06/17 15:08, Vincent Guittot wrote: > On 14 June 2017 at 09:55, Dietmar Eggemann wrote: > > > > On 06/12/2017 04:27 PM, Vincent Guittot wrote: > > > On 8 June 2017 at 09:55, Dietmar Eggemann > > > wrote: > > > > Hi Vincent, > > > >

Re: [PATCH 2/6] drivers base/arch_topology: frequency-invariant load-tracking support

Hi, On 14/06/17 15:08, Vincent Guittot wrote: > On 14 June 2017 at 09:55, Dietmar Eggemann wrote: > > > > On 06/12/2017 04:27 PM, Vincent Guittot wrote: > > > On 8 June 2017 at 09:55, Dietmar Eggemann > > > wrote: > > > > Hi Vincent, > > > > Thanks for the review! > > > > [...] > > > > >> @@

Re: [PATCH 0/6] arm, arm64: frequency- and cpu-invariant accounting support for task scheduler

This time hopefully fixing Vincent's email address.. On 12/06/17 14:00, Juri Lelli wrote: > Hi Dietmar, > > On 08/06/17 08:55, Dietmar Eggemann wrote: > > For a more accurate (i.e. frequency- and cpu-invariant) load-tracking > > the task scheduler needs a frequency-scaling a

Re: [PATCH 0/6] arm, arm64: frequency- and cpu-invariant accounting support for task scheduler

This time hopefully fixing Vincent's email address.. On 12/06/17 14:00, Juri Lelli wrote: > Hi Dietmar, > > On 08/06/17 08:55, Dietmar Eggemann wrote: > > For a more accurate (i.e. frequency- and cpu-invariant) load-tracking > > the task scheduler needs a frequency-scaling a

Re: [PATCH 0/6] arm, arm64: frequency- and cpu-invariant accounting support for task scheduler

freq governor and > checking the load-tracking signals of this task. > The whole set looks OK to me, and I tested it as well. Feel free to add my Reviewed-and-tested-by: Juri Lelli <juri.le...@arm.com> to it. Best, - Juri

Re: [PATCH 0/6] arm, arm64: frequency- and cpu-invariant accounting support for task scheduler

freq governor and > checking the load-tracking signals of this task. > The whole set looks OK to me, and I tested it as well. Feel free to add my Reviewed-and-tested-by: Juri Lelli to it. Best, - Juri

Re: [PATCH 2/2] sched/deadline: Don't return invalid cpu in cpudl_maximum_cpu()

On 09/06/17 11:43, Byungchul Park wrote: > On Thu, Jun 08, 2017 at 03:02:43PM +0100, Juri Lelli wrote: > > On 07/06/17 09:14, Byungchul Park wrote: > > > On Wed, Jun 07, 2017 at 08:42:24AM +0900, Byungchul Park wrote: > > > > On Tue, Jun 06, 2017 at 04:12:25PM +0100,

Re: [PATCH 2/2] sched/deadline: Don't return invalid cpu in cpudl_maximum_cpu()

On 09/06/17 11:43, Byungchul Park wrote: > On Thu, Jun 08, 2017 at 03:02:43PM +0100, Juri Lelli wrote: > > On 07/06/17 09:14, Byungchul Park wrote: > > > On Wed, Jun 07, 2017 at 08:42:24AM +0900, Byungchul Park wrote: > > > > On Tue, Jun 06, 2017 at 04:12:25PM +0100,

Re: [PATCH 2/2] sched/deadline: Don't return invalid cpu in cpudl_maximum_cpu()

On 07/06/17 09:14, Byungchul Park wrote: > On Wed, Jun 07, 2017 at 08:42:24AM +0900, Byungchul Park wrote: > > On Tue, Jun 06, 2017 at 04:12:25PM +0100, Juri Lelli wrote: > > > Hi, > > > > > > On 02/06/17 16:31, Byungchul Park wrote: [...] > > > >

Re: [PATCH 2/2] sched/deadline: Don't return invalid cpu in cpudl_maximum_cpu()

On 07/06/17 09:14, Byungchul Park wrote: > On Wed, Jun 07, 2017 at 08:42:24AM +0900, Byungchul Park wrote: > > On Tue, Jun 06, 2017 at 04:12:25PM +0100, Juri Lelli wrote: > > > Hi, > > > > > > On 02/06/17 16:31, Byungchul Park wrote: [...] > > > >

Re: [PATCH 01/10] sched/deadline: track the active utilization

On 08/06/17 09:36, Steven Rostedt wrote: > On Thu, 8 Jun 2017 10:05:55 +0100 > Juri Lelli <juri.le...@arm.com> wrote: > > > On 08/06/17 10:43, Luca Abeni wrote: > > > On Thu, 8 Jun 2017 10:31:25 +0200 > > > Ingo Molnar <mi...@kernel.org>

Re: [PATCH 01/10] sched/deadline: track the active utilization

On 08/06/17 09:36, Steven Rostedt wrote: > On Thu, 8 Jun 2017 10:05:55 +0100 > Juri Lelli wrote: > > > On 08/06/17 10:43, Luca Abeni wrote: > > > On Thu, 8 Jun 2017 10:31:25 +0200 > > > Ingo Molnar wrote: > > > > > > > * lu

Re: [PATCH 01/10] sched/deadline: track the active utilization

d from CPUi only at the 0 lag > > > time), a more theoretically sound solution is presented in the > > > next patches. > > > > > > Signed-off-by: Juri Lelli <juri.le...@arm.com> > > > Signed-off-by: Luca Abeni <luca.ab...@unitn.it>

Re: [PATCH 01/10] sched/deadline: track the active utilization

PUj. This mechanism is > > > implemented by modifying the pull and push functions. > > > Note: this is not fully correct from the theoretical point of view > > > (the utilization should be removed from CPUi only at the 0 lag > > > time), a more theoretically sound solut

Re: [PATCH 2/2] sched/deadline: Don't return invalid cpu in cpudl_maximum_cpu()

Hi, On 02/06/17 16:31, Byungchul Park wrote: > When the heap tree is empty, cp->elements[0].cpu has meaningless value. > We need to consider the case. > > Signed-off-by: Byungchul Park > --- > kernel/sched/cpudeadline.c | 3 ++- > 1 file changed, 2 insertions(+), 1

Re: [PATCH 2/2] sched/deadline: Don't return invalid cpu in cpudl_maximum_cpu()

Hi, On 02/06/17 16:31, Byungchul Park wrote: > When the heap tree is empty, cp->elements[0].cpu has meaningless value. > We need to consider the case. > > Signed-off-by: Byungchul Park > --- > kernel/sched/cpudeadline.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git

[PATCH v5 7/7] arm,arm64,drivers: add a prefix to drivers arch_topology interfaces

. Signed-off-by: Juri Lelli <juri.le...@arm.com> Acked-by: Russell King <rmk+ker...@armlinux.org.uk> Acked-by: Catalin Marinas <catalin.mari...@arm.com> --- Changes from v4: - as per discussion with Greg, Dietmar and Morten (off-line) the interface function have bee

[PATCH v5 7/7] arm,arm64,drivers: add a prefix to drivers arch_topology interfaces

. Signed-off-by: Juri Lelli Acked-by: Russell King Acked-by: Catalin Marinas --- Changes from v4: - as per discussion with Greg, Dietmar and Morten (off-line) the interface function have been renamed as s/atd_normalize_cpu_capacity/topology_normalize_cpu_scale/ s/atd_parse_cpu_capacity

[PATCH v5 6/7] arm,arm64,drivers: move externs in a new header file

Create a new header file (include/linux/arch_topology.h) and put there declarations of interfaces used by arm, arm64 and drivers code. Signed-off-by: Juri Lelli <juri.le...@arm.com> Acked-by: Russell King <rmk+ker...@armlinux.org.uk> Acked-by: Catalin Marinas <catalin.mari...

[PATCH v5 5/7] arm,arm64,drivers: reduce scope of cap_parsing_failed

) means cap_from _dt is set to false. For arm64 we can simply check if raw_capacity points to something, which is not if capacity parsing has failed. Suggested-by: Morten Rasmussen <morten.rasmus...@arm.com> Signed-off-by: Juri Lelli <juri.le...@arm.com> Acked-by: Russell K

[PATCH v5 6/7] arm,arm64,drivers: move externs in a new header file

Create a new header file (include/linux/arch_topology.h) and put there declarations of interfaces used by arm, arm64 and drivers code. Signed-off-by: Juri Lelli Acked-by: Russell King Acked-by: Catalin Marinas Acked-by: Greg Kroah-Hartman --- arch/arm/kernel/topology.c| 7 +-- arch

[PATCH v5 5/7] arm,arm64,drivers: reduce scope of cap_parsing_failed

) means cap_from _dt is set to false. For arm64 we can simply check if raw_capacity points to something, which is not if capacity parsing has failed. Suggested-by: Morten Rasmussen Signed-off-by: Juri Lelli Acked-by: Russell King Acked-by: Catalin Marinas Acked-by: Greg Kroah-Hartman --- arch

[PATCH v5 2/7] arm: fix return value of parse_cpu_capacity

3: parse cpu capacity-dmips-mhz from DT') Signed-off-by: Juri Lelli <juri.le...@arm.com> Acked-by: Russell King <rmk+ker...@armlinux.org.uk> Acked-by: Vincent Guittot <vincent.guit...@linaor.org> --- arch/arm/kernel/topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH v5 3/7] arm: remove wrong CONFIG_PROC_SYSCTL ifdef

ty attribute') Signed-off-by: Juri Lelli <juri.le...@arm.com> Acked-by: Russell King <rmk+ker...@armlinux.org.uk> --- arch/arm/kernel/topology.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c index 1b8ec3054642..40dd35aa46

[PATCH v5 4/7] arm, arm64: factorize common cpu capacity default code

<will.dea...@arm.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Signed-off-by: Juri Lelli <juri.le...@arm.com> Acked-by: Russell King <rmk+ker...@armlinux.org.uk> Acked-by: Catalin Marinas <catalin.mari...@arm.com> Acked-by: Greg Kroah-Hartman <gre...@linux

[PATCH v5 2/7] arm: fix return value of parse_cpu_capacity

parse_cpu_capacity() has to return 0 on failure, but it currently returns 1 instead if raw_capacity kcalloc failed. Fix it (by directly returning 0). Cc: Russell King Reported-by: Morten Rasmussen Fixes: 06073ee26775 ('ARM: 8621/3: parse cpu capacity-dmips-mhz from DT') Signed-off-by: Juri

[PATCH v5 3/7] arm: remove wrong CONFIG_PROC_SYSCTL ifdef

The sysfs cpu_capacity entry for each CPU has nothing to do with PROC_FS, nor it's in /proc/sys path. Remove such ifdef. Cc: Russell King Reported-and-suggested-by: Sudeep Holla Fixes: 7e5930aaef5d ('ARM: 8622/3: add sysfs cpu_capacity attribute') Signed-off-by: Juri Lelli Acked-by: Russell

[PATCH v5 4/7] arm, arm64: factorize common cpu capacity default code

additions. Suggested-by: Will Deacon Suggested-by: Mark Rutland Suggested-by: Catalin Marinas Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon Cc: Greg Kroah-Hartman Signed-off-by: Juri Lelli Acked-by: Russell King Acked-by: Catalin Marinas Acked-by: Greg Kroah-Hartman --- arch/arm

[PATCH v5 0/7] Fix issues and factorize arm/arm64 capacity information code

v2 - https://marc.info/?l=linux-kernel=148663344018205=2 v3 - http://marc.info/?l=linux-kernel=149062080701399=2 v4 - https://marc.info/?l=linux-kernel=149269955206646=2 Juri Lelli (7): Documentation: arm: fix wrong reference number in DT definition arm: fix return value

[PATCH v5 0/7] Fix issues and factorize arm/arm64 capacity information code

v2 - https://marc.info/?l=linux-kernel=148663344018205=2 v3 - http://marc.info/?l=linux-kernel=149062080701399=2 v4 - https://marc.info/?l=linux-kernel=149269955206646=2 Juri Lelli (7): Documentation: arm: fix wrong reference number in DT definition arm: fix return value

[PATCH v5 1/7] Documentation: arm: fix wrong reference number in DT definition

Reference to cpu capacity binding has a wrong number. Fix it. Reported-by: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> Signed-off-by: Juri Lelli <juri.le...@arm.com> Acked-by: Rob Herring <r...@kernel.org> Acked-by: Russell King <rmk+ker...@armlinux.org.uk> ---

[PATCH v5 1/7] Documentation: arm: fix wrong reference number in DT definition

Reference to cpu capacity binding has a wrong number. Fix it. Reported-by: Lorenzo Pieralisi Signed-off-by: Juri Lelli Acked-by: Rob Herring Acked-by: Russell King --- Documentation/devicetree/bindings/arm/cpus.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [RFC PATCH 1/2] sched/rt: add utilization tracking

On 31/05/17 12:30, Peter Zijlstra wrote: > On Wed, May 31, 2017 at 11:40:47AM +0200, Peter Zijlstra wrote: > > On Wed, May 24, 2017 at 11:00:51AM +0200, Vincent Guittot wrote: > > > schedutil governor relies on cfs_rq's util_avg to choose the OPP when cfs > > > tasks are running. When the CPU is

Re: [RFC PATCH 1/2] sched/rt: add utilization tracking

On 31/05/17 12:30, Peter Zijlstra wrote: > On Wed, May 31, 2017 at 11:40:47AM +0200, Peter Zijlstra wrote: > > On Wed, May 24, 2017 at 11:00:51AM +0200, Vincent Guittot wrote: > > > schedutil governor relies on cfs_rq's util_avg to choose the OPP when cfs > > > tasks are running. When the CPU is

Re: [PATCH v4 8/8] arm,arm64,drivers: add a prefix to drivers arch_topology interfaces

On 29/05/17 12:46, Dietmar Eggemann wrote: > On 05/29/2017 11:58 AM, Greg KH wrote: > > On Mon, May 29, 2017 at 11:20:24AM +0200, Dietmar Eggemann wrote: > > > Hi Greg, > > > > > > On 05/26/2017 08:36 PM, Greg KH wrote: > > > > On Fri, Ma

Re: [PATCH v4 8/8] arm,arm64,drivers: add a prefix to drivers arch_topology interfaces

On 29/05/17 12:46, Dietmar Eggemann wrote: > On 05/29/2017 11:58 AM, Greg KH wrote: > > On Mon, May 29, 2017 at 11:20:24AM +0200, Dietmar Eggemann wrote: > > > Hi Greg, > > > > > > On 05/26/2017 08:36 PM, Greg KH wrote: > > > > On Fri, Ma

Re: [PATCH v4 8/8] arm,arm64,drivers: add a prefix to drivers arch_topology interfaces

Hi, On 25/05/17 15:18, Greg KH wrote: > On Thu, Apr 20, 2017 at 03:43:16PM +0100, Juri Lelli wrote: > > Now that some functions that deal with arch topology information live > > under drivers, there is a clash of naming that might create confusion. > > > > Tidy thin

Re: [PATCH v4 8/8] arm,arm64,drivers: add a prefix to drivers arch_topology interfaces

Hi, On 25/05/17 15:18, Greg KH wrote: > On Thu, Apr 20, 2017 at 03:43:16PM +0100, Juri Lelli wrote: > > Now that some functions that deal with arch topology information live > > under drivers, there is a clash of naming that might create confusion. > > > > Tidy thin

Re: [PATCH v4 0/8] Fix issues and factorize arm/arm64 capacity information code

On 25/05/17 15:18, Greg KH wrote: > On Wed, May 24, 2017 at 03:45:15PM +0100, Juri Lelli wrote: > > Hi, > > > > On 11/05/17 11:27, Juri Lelli wrote: > > > On 11/05/17 10:59, Greg KH wrote: > > > > On Thu, May 11, 2017 at 09:48:30AM

Re: [PATCH v4 0/8] Fix issues and factorize arm/arm64 capacity information code

On 25/05/17 15:18, Greg KH wrote: > On Wed, May 24, 2017 at 03:45:15PM +0100, Juri Lelli wrote: > > Hi, > > > > On 11/05/17 11:27, Juri Lelli wrote: > > > On 11/05/17 10:59, Greg KH wrote: > > > > On Thu, May 11, 2017 at 09:48:30AM

Re: [PATCH v4 0/8] Fix issues and factorize arm/arm64 capacity information code

Hi, On 11/05/17 11:27, Juri Lelli wrote: > On 11/05/17 10:59, Greg KH wrote: > > On Thu, May 11, 2017 at 09:48:30AM +0100, Juri Lelli wrote: > > > Hi Greg, > > > > > > I'm not sure what your plans are with this set. Are we targeting 4.12? > > > >

Re: [PATCH v4 0/8] Fix issues and factorize arm/arm64 capacity information code

Hi, On 11/05/17 11:27, Juri Lelli wrote: > On 11/05/17 10:59, Greg KH wrote: > > On Thu, May 11, 2017 at 09:48:30AM +0100, Juri Lelli wrote: > > > Hi Greg, > > > > > > I'm not sure what your plans are with this set. Are we targeting 4.12? > > > >

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

On 24/05/17 11:41, Peter Zijlstra wrote: > On Wed, May 24, 2017 at 10:25:05AM +0100, Juri Lelli wrote: > > Hi, > > > > On 23/05/17 22:23, Peter Zijlstra wrote: > > > On Tue, May 23, 2017 at 09:53:43AM +0100, Juri Lelli wrote: > > > > > > > A po

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

On 24/05/17 11:41, Peter Zijlstra wrote: > On Wed, May 24, 2017 at 10:25:05AM +0100, Juri Lelli wrote: > > Hi, > > > > On 23/05/17 22:23, Peter Zijlstra wrote: > > > On Tue, May 23, 2017 at 09:53:43AM +0100, Juri Lelli wrote: > > > > > > > A po

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

Hi, On 23/05/17 20:52, Peter Zijlstra wrote: > On Tue, May 23, 2017 at 09:53:46AM +0100, Juri Lelli wrote: > > diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h > > index e2a6c7b3510b..72723859ef74 100644 > > --- a/include/uapi/linux/sched.h > > +++ b

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

Hi, On 23/05/17 20:52, Peter Zijlstra wrote: > On Tue, May 23, 2017 at 09:53:46AM +0100, Juri Lelli wrote: > > diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h > > index e2a6c7b3510b..72723859ef74 100644 > > --- a/include/uapi/linux/sched.h > > +++ b

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

Hi, On 23/05/17 22:23, Peter Zijlstra wrote: > On Tue, May 23, 2017 at 09:53:43AM +0100, Juri Lelli wrote: > > > A point that is still very much up for discussion (more that the others :) > > is > > how we implement frequency/cpu scaling. SCHED_FLAG_RECLAIM tasks on

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

Hi, On 23/05/17 22:23, Peter Zijlstra wrote: > On Tue, May 23, 2017 at 09:53:43AM +0100, Juri Lelli wrote: > > > A point that is still very much up for discussion (more that the others :) > > is > > how we implement frequency/cpu scaling. SCHED_FLAG_RECLAIM tasks on

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

Hi, On 23/05/17 21:04, Peter Zijlstra wrote: > On Tue, May 23, 2017 at 09:53:47AM +0100, Juri Lelli wrote: > > @@ -157,14 +158,13 @@ static unsigned int get_next_freq(struct sugov_policy > > *sg_policy, > > return cpufreq_driver_resolve_freq(policy, freq); > >

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

Hi, On 23/05/17 21:04, Peter Zijlstra wrote: > On Tue, May 23, 2017 at 09:53:47AM +0100, Juri Lelli wrote: > > @@ -157,14 +158,13 @@ static unsigned int get_next_freq(struct sugov_policy > > *sg_policy, > > return cpufreq_driver_resolve_freq(policy, freq); > >

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

Hi, On 24/05/17 09:01, Peter Zijlstra wrote: > On Wed, May 24, 2017 at 01:30:36AM +0200, Rafael J. Wysocki wrote: > > On Tuesday, May 23, 2017 09:29:27 PM Peter Zijlstra wrote: > > > On Tue, May 23, 2017 at 09:53:47AM +0100, Juri Lelli wrote: > > > > To be abl

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

Hi, On 24/05/17 09:01, Peter Zijlstra wrote: > On Wed, May 24, 2017 at 01:30:36AM +0200, Rafael J. Wysocki wrote: > > On Tuesday, May 23, 2017 09:29:27 PM Peter Zijlstra wrote: > > > On Tue, May 23, 2017 at 09:53:47AM +0100, Juri Lelli wrote: > > > > To be abl

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