Re: [PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

On 14/06/18 15:18, Quentin Perret wrote: > On Thursday 14 Jun 2018 at 16:11:18 (+0200), Juri Lelli wrote: > > On 14/06/18 14:58, Quentin Perret wrote: > > > > [...] > > > > > Hmm not sure if this can help but I think that rebuild_sched_domains() > >

Re: [PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

On 14/06/18 14:58, Quentin Perret wrote: [...] > Hmm not sure if this can help but I think that rebuild_sched_domains() > does _not_ take the hotplug lock before calling partition_sched_domains() > when CONFIG_CPUSETS=n. But it does take it for CONFIG_CPUSETS=y. Did you mean cpuset_mutex?

Re: [PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

On 14/06/18 15:18, Quentin Perret wrote: > On Thursday 14 Jun 2018 at 16:11:18 (+0200), Juri Lelli wrote: > > On 14/06/18 14:58, Quentin Perret wrote: > > > > [...] > > > > > Hmm not sure if this can help but I think that rebuild_sched_domains() > >

Re: [PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

On 14/06/18 14:58, Quentin Perret wrote: [...] > Hmm not sure if this can help but I think that rebuild_sched_domains() > does _not_ take the hotplug lock before calling partition_sched_domains() > when CONFIG_CPUSETS=n. But it does take it for CONFIG_CPUSETS=y. Did you mean cpuset_mutex?

Re: [PATCH v4 4/5] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

On 14/06/18 09:45, Steven Rostedt wrote: > On Wed, 13 Jun 2018 14:17:10 +0200 > Ju > > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c > > index b42037e6e81d..d26fd4795aa3 100644 > > --- a/kernel/cgroup/cpuset.c > > +++ b/kernel/cgroup/cpuset.c > > @@ -2409,6 +2409,22 @@ void __init

Re: [PATCH v4 4/5] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

On 14/06/18 09:45, Steven Rostedt wrote: > On Wed, 13 Jun 2018 14:17:10 +0200 > Ju > > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c > > index b42037e6e81d..d26fd4795aa3 100644 > > --- a/kernel/cgroup/cpuset.c > > +++ b/kernel/cgroup/cpuset.c > > @@ -2409,6 +2409,22 @@ void __init

Re: [PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

On 14/06/18 09:47, Steven Rostedt wrote: > On Thu, 14 Jun 2018 15:42:34 +0200 > Juri Lelli wrote: > > > On 14/06/18 09:33, Steven Rostedt wrote: > > > On Wed, 13 Jun 2018 14:17:07 +0200 > > > Juri Lelli wrote: > > > > > > > From: Mathie

Re: [PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

On 14/06/18 09:47, Steven Rostedt wrote: > On Thu, 14 Jun 2018 15:42:34 +0200 > Juri Lelli wrote: > > > On 14/06/18 09:33, Steven Rostedt wrote: > > > On Wed, 13 Jun 2018 14:17:07 +0200 > > > Juri Lelli wrote: > > > > > > > From: Mathie

Re: [PATCH v4 2/5] sched/topology: Adding function partition_sched_domains_locked()

On 14/06/18 09:35, Steven Rostedt wrote: > On Wed, 13 Jun 2018 14:17:08 +0200 > Juri Lelli wrote: [...] > > +/* > > + * Call with hotplug lock held > > + */ > > +void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[], > > +

Re: [PATCH v4 2/5] sched/topology: Adding function partition_sched_domains_locked()

On 14/06/18 09:35, Steven Rostedt wrote: > On Wed, 13 Jun 2018 14:17:08 +0200 > Juri Lelli wrote: [...] > > +/* > > + * Call with hotplug lock held > > + */ > > +void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[], > > +

Re: [PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

On 14/06/18 09:33, Steven Rostedt wrote: > On Wed, 13 Jun 2018 14:17:07 +0200 > Juri Lelli wrote: > > > From: Mathieu Poirier > > > > The comment above function partition_sched_domains() clearly state that > > the cpu_hotplug_lock should be held

Re: [PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

On 14/06/18 09:33, Steven Rostedt wrote: > On Wed, 13 Jun 2018 14:17:07 +0200 > Juri Lelli wrote: > > > From: Mathieu Poirier > > > > The comment above function partition_sched_domains() clearly state that > > the cpu_hotplug_lock should be held

[PATCH v4 3/5] sched/core: Streamlining calls to task_rq_unlock()

From: Mathieu Poirier Calls to task_rq_unlock() are done several times in function __sched_setscheduler(). This is fine when only the rq lock needs to be handled but not so much when other locks come into play. This patch streamlines the release of the rq lock so that only one location need to

[PATCH v4 3/5] sched/core: Streamlining calls to task_rq_unlock()

From: Mathieu Poirier Calls to task_rq_unlock() are done several times in function __sched_setscheduler(). This is fine when only the rq lock needs to be handled but not so much when other locks come into play. This patch streamlines the release of the rq lock so that only one location need to

[PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

Lelli Signed-off-by: Mathieu Poirier [modified changelog] Signed-off-by: Juri Lelli --- kernel/sched/topology.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 61a1125c1ae4..96eee22fafe8 100644 --- a/kernel/sched/topology.c +++ b/kernel

[PATCH v4 1/5] sched/topology: Add check to backup comment about hotplug lock

Lelli Signed-off-by: Mathieu Poirier [modified changelog] Signed-off-by: Juri Lelli --- kernel/sched/topology.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c index 61a1125c1ae4..96eee22fafe8 100644 --- a/kernel/sched/topology.c +++ b/kernel

[PATCH v4 0/5] sched/deadline: fix cpusets bandwidth accounting

Hi, This is v4 of a series of patches, authored by Mathieu (thanks for your work and for allowing me to try to move this forward), with the intent of fixing a long standing issue of SCHED_DEADLINE bandwidth accounting. As originally reported by Steve [1], when hotplug and/or (certain) cpuset

[PATCH v4 0/5] sched/deadline: fix cpusets bandwidth accounting

Hi, This is v4 of a series of patches, authored by Mathieu (thanks for your work and for allowing me to try to move this forward), with the intent of fixing a long standing issue of SCHED_DEADLINE bandwidth accounting. As originally reported by Steve [1], when hotplug and/or (certain) cpuset

[PATCH v4 4/5] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

-by: Juri Lelli --- include/linux/cpuset.h | 6 ++ kernel/cgroup/cpuset.c | 16 kernel/sched/core.c| 14 ++ 3 files changed, 36 insertions(+) diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h index 934633a05d20..a1970862ab8e 100644 --- a/include/linux

[PATCH v4 2/5] sched/topology: Adding function partition_sched_domains_locked()

From: Mathieu Poirier Introducing function partition_sched_domains_locked() by taking the mutex locking code out of the original function. That way the work done by partition_sched_domains_locked() can be reused without dropping the mutex lock. No change of functionality is introduced by this

[PATCH v4 5/5] cpuset: Rebuild root domain deadline accounting information

From: Mathieu Poirier When the topology of root domains is modified by CPUset or CPUhotplug operations information about the current deadline bandwidth held in the root domain is lost. This patch address the issue by recalculating the lost deadline bandwidth information by circling through the

[PATCH v4 2/5] sched/topology: Adding function partition_sched_domains_locked()

From: Mathieu Poirier Introducing function partition_sched_domains_locked() by taking the mutex locking code out of the original function. That way the work done by partition_sched_domains_locked() can be reused without dropping the mutex lock. No change of functionality is introduced by this

[PATCH v4 5/5] cpuset: Rebuild root domain deadline accounting information

From: Mathieu Poirier When the topology of root domains is modified by CPUset or CPUhotplug operations information about the current deadline bandwidth held in the root domain is lost. This patch address the issue by recalculating the lost deadline bandwidth information by circling through the

[PATCH v4 4/5] sched/core: Prevent race condition between cpuset and __sched_setscheduler()

-by: Juri Lelli --- include/linux/cpuset.h | 6 ++ kernel/cgroup/cpuset.c | 16 kernel/sched/core.c| 14 ++ 3 files changed, 36 insertions(+) diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h index 934633a05d20..a1970862ab8e 100644 --- a/include/linux

Re: [PATCH v6 06/11] cpufreq/schedutil: use dl utilization tracking

On 08/06/18 14:54, Juri Lelli wrote: > On 08/06/18 14:48, Vincent Guittot wrote: > > On 8 June 2018 at 14:39, Juri Lelli wrote: > > > Hi Vincent, > > > > > > On 08/06/18 14:09, Vincent Guittot wrote: > > >> Now that we have both the

Re: [PATCH v6 06/11] cpufreq/schedutil: use dl utilization tracking

On 08/06/18 14:54, Juri Lelli wrote: > On 08/06/18 14:48, Vincent Guittot wrote: > > On 8 June 2018 at 14:39, Juri Lelli wrote: > > > Hi Vincent, > > > > > > On 08/06/18 14:09, Vincent Guittot wrote: > > >> Now that we have both the

Re: [PATCH v6 06/11] cpufreq/schedutil: use dl utilization tracking

On 08/06/18 14:48, Vincent Guittot wrote: > On 8 June 2018 at 14:39, Juri Lelli wrote: > > Hi Vincent, > > > > On 08/06/18 14:09, Vincent Guittot wrote: > >> Now that we have both the dl class bandwidth requirement and the dl class > >> utilization, we

Re: [PATCH v6 06/11] cpufreq/schedutil: use dl utilization tracking

On 08/06/18 14:48, Vincent Guittot wrote: > On 8 June 2018 at 14:39, Juri Lelli wrote: > > Hi Vincent, > > > > On 08/06/18 14:09, Vincent Guittot wrote: > >> Now that we have both the dl class bandwidth requirement and the dl class > >> utilization, we

Re: [PATCH v6 06/11] cpufreq/schedutil: use dl utilization tracking

Hi Vincent, On 08/06/18 14:09, Vincent Guittot wrote: > Now that we have both the dl class bandwidth requirement and the dl class > utilization, we can detect when CPU is fully used so we should run at max. > Otherwise, we keep using the dl bandwidth requirement to define the > utilization of the

Re: [PATCH v6 06/11] cpufreq/schedutil: use dl utilization tracking

Hi Vincent, On 08/06/18 14:09, Vincent Guittot wrote: > Now that we have both the dl class bandwidth requirement and the dl class > utilization, we can detect when CPU is fully used so we should run at max. > Otherwise, we keep using the dl bandwidth requirement to define the > utilization of the

Re: [RFC PATCH v3 09/10] sched/fair: Select an energy-efficient CPU on task wake-up

On 08/06/18 12:19, Quentin Perret wrote: > On Friday 08 Jun 2018 at 12:24:46 (+0200), Juri Lelli wrote: > > Hi, > > > > On 21/05/18 15:25, Quentin Perret wrote: > > > > [...] > > > > > +static int find_energy_efficient_cpu(struct task_struct

Re: [RFC PATCH v3 09/10] sched/fair: Select an energy-efficient CPU on task wake-up

On 08/06/18 12:19, Quentin Perret wrote: > On Friday 08 Jun 2018 at 12:24:46 (+0200), Juri Lelli wrote: > > Hi, > > > > On 21/05/18 15:25, Quentin Perret wrote: > > > > [...] > > > > > +static int find_energy_efficient_cpu(struct task_struct

Re: [RFC PATCH v3 07/10] sched/fair: Introduce an energy estimation helper function

On 21/05/18 15:25, Quentin Perret wrote: [...] > +static long compute_energy(struct task_struct *p, int dst_cpu) > +{ > + long util, max_util, sum_util, energy = 0; > + struct sched_energy_fd *sfd; > + int cpu; > + > + for_each_freq_domain(sfd) { > + max_util =

Re: [RFC PATCH v3 07/10] sched/fair: Introduce an energy estimation helper function

On 21/05/18 15:25, Quentin Perret wrote: [...] > +static long compute_energy(struct task_struct *p, int dst_cpu) > +{ > + long util, max_util, sum_util, energy = 0; > + struct sched_energy_fd *sfd; > + int cpu; > + > + for_each_freq_domain(sfd) { > + max_util =

Re: [RFC PATCH v3 09/10] sched/fair: Select an energy-efficient CPU on task wake-up

Hi, On 21/05/18 15:25, Quentin Perret wrote: [...] > +static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) > +{ > + unsigned long cur_energy, prev_energy, best_energy, cpu_cap, task_util; > + int cpu, best_energy_cpu = prev_cpu; > + struct sched_energy_fd *sfd;

Re: [RFC PATCH v3 09/10] sched/fair: Select an energy-efficient CPU on task wake-up

Hi, On 21/05/18 15:25, Quentin Perret wrote: [...] > +static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) > +{ > + unsigned long cur_energy, prev_energy, best_energy, cpu_cap, task_util; > + int cpu, best_energy_cpu = prev_cpu; > + struct sched_energy_fd *sfd;

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

On 08/06/18 09:25, Quentin Perret wrote: > Hi Dietmar, > > On Thursday 07 Jun 2018 at 17:55:32 (+0200), Dietmar Eggemann wrote: [...] > > IMHO, part of the problem why this might be harder to understand is the fact > > that the patches show the use of the 2. init call > >

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

On 08/06/18 09:25, Quentin Perret wrote: > Hi Dietmar, > > On Thursday 07 Jun 2018 at 17:55:32 (+0200), Dietmar Eggemann wrote: [...] > > IMHO, part of the problem why this might be harder to understand is the fact > > that the patches show the use of the 2. init call > >

Re: [RFC PATCH v3 05/10] sched/topology: Reference the Energy Model of CPUs when available

On 07/06/18 17:02, Quentin Perret wrote: > On Thursday 07 Jun 2018 at 16:44:22 (+0200), Juri Lelli wrote: > > Hi, > > > > On 21/05/18 15:25, Quentin Perret wrote: > > > In order to use EAS, the task scheduler has to know about the Energy > > > Model (E

Re: [RFC PATCH v3 05/10] sched/topology: Reference the Energy Model of CPUs when available

On 07/06/18 17:02, Quentin Perret wrote: > On Thursday 07 Jun 2018 at 16:44:22 (+0200), Juri Lelli wrote: > > Hi, > > > > On 21/05/18 15:25, Quentin Perret wrote: > > > In order to use EAS, the task scheduler has to know about the Energy > > > Model (E

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

On 07/06/18 16:19, Quentin Perret wrote: > Hi Juri, > > On Thursday 07 Jun 2018 at 16:44:09 (+0200), Juri Lelli wrote: > > On 21/05/18 15:24, Quentin Perret wrote: [...] > > > +static void fd_update_cs_table(struct em_cs_table *cs_table, int cpu) > > &

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

On 07/06/18 16:19, Quentin Perret wrote: > Hi Juri, > > On Thursday 07 Jun 2018 at 16:44:09 (+0200), Juri Lelli wrote: > > On 21/05/18 15:24, Quentin Perret wrote: [...] > > > +static void fd_update_cs_table(struct em_cs_table *cs_table, int cpu) > > &

Re: [RFC PATCH v3 05/10] sched/topology: Reference the Energy Model of CPUs when available

Hi, On 21/05/18 15:25, Quentin Perret wrote: > In order to use EAS, the task scheduler has to know about the Energy > Model (EM) of the platform. This commit extends the scheduler topology > code to take references on the frequency domains objects of the EM > framework for all online CPUs. Hence,

Re: [RFC PATCH v3 05/10] sched/topology: Reference the Energy Model of CPUs when available

Hi, On 21/05/18 15:25, Quentin Perret wrote: > In order to use EAS, the task scheduler has to know about the Energy > Model (EM) of the platform. This commit extends the scheduler topology > code to take references on the frequency domains objects of the EM > framework for all online CPUs. Hence,

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

On 21/05/18 15:24, Quentin Perret wrote: > Several subsystems in the kernel (scheduler and/or thermal at the time > of writing) can benefit from knowing about the energy consumed by CPUs. > Yet, this information can come from different sources (DT or firmware for > example), in different formats,

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

On 21/05/18 15:24, Quentin Perret wrote: > Several subsystems in the kernel (scheduler and/or thermal at the time > of writing) can benefit from knowing about the energy consumed by CPUs. > Yet, this information can come from different sources (DT or firmware for > example), in different formats,

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

Hi Quentin, On 21/05/18 15:24, Quentin Perret wrote: [...] > +#ifdef CONFIG_ENERGY_MODEL [...] > +struct em_data_callback { > + /** > + * active_power() - Provide power at the next capacity state of a CPU > + * @power : Active power at the capacity state (modified) > +

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

Hi Quentin, On 21/05/18 15:24, Quentin Perret wrote: [...] > +#ifdef CONFIG_ENERGY_MODEL [...] > +struct em_data_callback { > + /** > + * active_power() - Provide power at the next capacity state of a CPU > + * @power : Active power at the capacity state (modified) > +

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

On 06/06/18 15:37, Quentin Perret wrote: > Hi Dietmar, > > On Wednesday 06 Jun 2018 at 15:12:15 (+0200), Dietmar Eggemann wrote: > > > +static void fd_update_cs_table(struct em_cs_table *cs_table, int cpu) > > > +{ > > > + unsigned long cmax = arch_scale_cpu_capacity(NULL, cpu); > > > + int

Re: [RFC PATCH v3 03/10] PM: Introduce an Energy Model management framework

On 06/06/18 15:37, Quentin Perret wrote: > Hi Dietmar, > > On Wednesday 06 Jun 2018 at 15:12:15 (+0200), Dietmar Eggemann wrote: > > > +static void fd_update_cs_table(struct em_cs_table *cs_table, int cpu) > > > +{ > > > + unsigned long cmax = arch_scale_cpu_capacity(NULL, cpu); > > > + int

Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking

On 05/06/18 16:11, Patrick Bellasi wrote: [...] > If I run an experiment with your example above, while using the > performance governor to rule out any possible scale invariance > difference, here is what I measure: > >Task1 (40ms delayed by the following Task2): >

Re: [PATCH 2/2] sched/fair: util_est: add running_sum tracking

On 05/06/18 16:11, Patrick Bellasi wrote: [...] > If I run an experiment with your example above, while using the > performance governor to rule out any possible scale invariance > difference, here is what I measure: > >Task1 (40ms delayed by the following Task2): >

Re: [PATCH v5 00/10] track CPU utilization

On 05/06/18 16:18, Peter Zijlstra wrote: > On Mon, Jun 04, 2018 at 08:08:58PM +0200, Vincent Guittot wrote: [...] > > As you mentioned, scale_rt_capacity give the remaining capacity for > > cfs and it will behave like cfs util_avg now that it uses PELT. So as > > long as cfs util_avg <

Re: [PATCH v5 00/10] track CPU utilization

On 05/06/18 16:18, Peter Zijlstra wrote: > On Mon, Jun 04, 2018 at 08:08:58PM +0200, Vincent Guittot wrote: [...] > > As you mentioned, scale_rt_capacity give the remaining capacity for > > cfs and it will behave like cfs util_avg now that it uses PELT. So as > > long as cfs util_avg <

Re: [PATCH v5 00/10] track CPU utilization

On 05/06/18 15:01, Quentin Perret wrote: > On Tuesday 05 Jun 2018 at 15:15:18 (+0200), Juri Lelli wrote: > > On 05/06/18 14:05, Quentin Perret wrote: > > > On Tuesday 05 Jun 2018 at 14:11:53 (+0200), Juri Lelli wrote: > > > > Hi Quentin, > > > > >

Re: [PATCH v5 00/10] track CPU utilization

On 05/06/18 15:01, Quentin Perret wrote: > On Tuesday 05 Jun 2018 at 15:15:18 (+0200), Juri Lelli wrote: > > On 05/06/18 14:05, Quentin Perret wrote: > > > On Tuesday 05 Jun 2018 at 14:11:53 (+0200), Juri Lelli wrote: > > > > Hi Quentin, > > > > >

Re: [PATCH v5 00/10] track CPU utilization

On 05/06/18 14:05, Quentin Perret wrote: > On Tuesday 05 Jun 2018 at 14:11:53 (+0200), Juri Lelli wrote: > > Hi Quentin, > > > > On 05/06/18 11:57, Quentin Perret wrote: > > > > [...] > > > > > What about the diff below (just a quick hack t

Re: [PATCH v5 00/10] track CPU utilization

On 05/06/18 14:05, Quentin Perret wrote: > On Tuesday 05 Jun 2018 at 14:11:53 (+0200), Juri Lelli wrote: > > Hi Quentin, > > > > On 05/06/18 11:57, Quentin Perret wrote: > > > > [...] > > > > > What about the diff below (just a quick hack t

Re: [PATCH v5 00/10] track CPU utilization

Hi Quentin, On 05/06/18 11:57, Quentin Perret wrote: [...] > What about the diff below (just a quick hack to show the idea) applied > on tip/sched/core ? > > ---8<--- > diff --git a/kernel/sched/cpufreq_schedutil.c > b/kernel/sched/cpufreq_schedutil.c > index a8ba6d1f262a..23a4fb1c2c25 100644

Re: [PATCH v5 00/10] track CPU utilization

Hi Quentin, On 05/06/18 11:57, Quentin Perret wrote: [...] > What about the diff below (just a quick hack to show the idea) applied > on tip/sched/core ? > > ---8<--- > diff --git a/kernel/sched/cpufreq_schedutil.c > b/kernel/sched/cpufreq_schedutil.c > index a8ba6d1f262a..23a4fb1c2c25 100644

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 04/06/18 09:14, Vincent Guittot wrote: > On 4 June 2018 at 09:04, Juri Lelli wrote: > > Hi Vincent, > > > > On 04/06/18 08:41, Vincent Guittot wrote: > >> On 1 June 2018 at 19:45, Joel Fernandes wrote: > >> > On Fri, Jun 01, 2018

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 04/06/18 09:14, Vincent Guittot wrote: > On 4 June 2018 at 09:04, Juri Lelli wrote: > > Hi Vincent, > > > > On 04/06/18 08:41, Vincent Guittot wrote: > >> On 1 June 2018 at 19:45, Joel Fernandes wrote: > >> > On Fri, Jun 01, 2018

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

Hi Vincent, On 04/06/18 08:41, Vincent Guittot wrote: > On 1 June 2018 at 19:45, Joel Fernandes wrote: > > On Fri, Jun 01, 2018 at 03:53:07PM +0200, Vincent Guittot wrote: [...] > > IMO I feel its overkill to account dl_avg when we already have DL's running > > bandwidth we can use. I

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

Hi Vincent, On 04/06/18 08:41, Vincent Guittot wrote: > On 1 June 2018 at 19:45, Joel Fernandes wrote: > > On Fri, Jun 01, 2018 at 03:53:07PM +0200, Vincent Guittot wrote: [...] > > IMO I feel its overkill to account dl_avg when we already have DL's running > > bandwidth we can use. I

[tip:sched/urgent] sched/deadline: Fix missing clock update

Commit-ID: ecda2b66e263dfd6c1d6113add19150f4e235bb3 Gitweb: https://git.kernel.org/tip/ecda2b66e263dfd6c1d6113add19150f4e235bb3 Author: Juri Lelli AuthorDate: Wed, 30 May 2018 18:08:09 +0200 Committer: Ingo Molnar CommitDate: Thu, 31 May 2018 12:27:13 +0200 sched/deadline: Fix missing

[tip:sched/urgent] sched/deadline: Fix missing clock update

Commit-ID: ecda2b66e263dfd6c1d6113add19150f4e235bb3 Gitweb: https://git.kernel.org/tip/ecda2b66e263dfd6c1d6113add19150f4e235bb3 Author: Juri Lelli AuthorDate: Wed, 30 May 2018 18:08:09 +0200 Committer: Ingo Molnar CommitDate: Thu, 31 May 2018 12:27:13 +0200 sched/deadline: Fix missing

Re: [PATCH v5 03/10] cpufreq/schedutil: add rt utilization tracking

On 30/05/18 17:46, Quentin Perret wrote: > Hi Vincent, > > On Friday 25 May 2018 at 15:12:24 (+0200), Vincent Guittot wrote: > > Add both cfs and rt utilization when selecting an OPP for cfs tasks as rt > > can preempt and steal cfs's running time. > > > > Signed-off-by: Vincent Guittot > > ---

Re: [PATCH v5 03/10] cpufreq/schedutil: add rt utilization tracking

On 30/05/18 17:46, Quentin Perret wrote: > Hi Vincent, > > On Friday 25 May 2018 at 15:12:24 (+0200), Vincent Guittot wrote: > > Add both cfs and rt utilization when selecting an OPP for cfs tasks as rt > > can preempt and steal cfs's running time. > > > > Signed-off-by: Vincent Guittot > > ---

[PATCH] sched/deadline: Fix missing clock update

l test robot Signed-off-by: Juri Lelli Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Luca Abeni Cc: Claudio Scordino Cc: linux-kernel@vger.kernel.org --- This was actually first spotted by lkp-robot[1], but the fix never made it to the list as a proper patch. Apologies. :/ [1] https://www.spini

[PATCH] sched/deadline: Fix missing clock update

l test robot Signed-off-by: Juri Lelli Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Luca Abeni Cc: Claudio Scordino Cc: linux-kernel@vger.kernel.org --- This was actually first spotted by lkp-robot[1], but the fix never made it to the list as a proper patch. Apologies. :/ [1] https://www.spini

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 30/05/18 09:37, Quentin Perret wrote: > On Tuesday 29 May 2018 at 11:52:03 (+0200), Juri Lelli wrote: > > On 29/05/18 09:40, Quentin Perret wrote: > > > Hi Vincent, > > > > > > On Friday 25 May 2018 at 15:12:26 (+0200), Vincent Guittot wrote: > &

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 30/05/18 09:37, Quentin Perret wrote: > On Tuesday 29 May 2018 at 11:52:03 (+0200), Juri Lelli wrote: > > On 29/05/18 09:40, Quentin Perret wrote: > > > Hi Vincent, > > > > > > On Friday 25 May 2018 at 15:12:26 (+0200), Vincent Guittot wrote: > &

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 29/05/18 09:40, Quentin Perret wrote: > Hi Vincent, > > On Friday 25 May 2018 at 15:12:26 (+0200), Vincent Guittot wrote: > > Now that we have both the dl class bandwidth requirement and the dl class > > utilization, we can use the max of the 2 values when agregating the > > utilization of the

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 29/05/18 09:40, Quentin Perret wrote: > Hi Vincent, > > On Friday 25 May 2018 at 15:12:26 (+0200), Vincent Guittot wrote: > > Now that we have both the dl class bandwidth requirement and the dl class > > utilization, we can use the max of the 2 values when agregating the > > utilization of the

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 29/05/18 08:48, Vincent Guittot wrote: > On 29 May 2018 at 08:31, Juri Lelli wrote: > > On 28/05/18 22:08, Joel Fernandes wrote: > >> On Mon, May 28, 2018 at 12:12:34PM +0200, Juri Lelli wrote: > >> [..] > >> > > + > >> > > + util =

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 29/05/18 08:48, Vincent Guittot wrote: > On 29 May 2018 at 08:31, Juri Lelli wrote: > > On 28/05/18 22:08, Joel Fernandes wrote: > >> On Mon, May 28, 2018 at 12:12:34PM +0200, Juri Lelli wrote: > >> [..] > >> > > + > >> > > + util =

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 28/05/18 22:08, Joel Fernandes wrote: > On Mon, May 28, 2018 at 12:12:34PM +0200, Juri Lelli wrote: > [..] > > > + > > > + util = max_t(unsigned long, util, READ_ONCE(rq->avg_dl.util_avg)); > > > + > > > + return util; > > > > A

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 28/05/18 22:08, Joel Fernandes wrote: > On Mon, May 28, 2018 at 12:12:34PM +0200, Juri Lelli wrote: > [..] > > > + > > > + util = max_t(unsigned long, util, READ_ONCE(rq->avg_dl.util_avg)); > > > + > > > + return util; > > > > A

Re: [PATCH v8 4/6] cpuset: Make generate_sched_domains() recognize isolated_cpus

On 28/05/18 21:24, Waiman Long wrote: > On 05/28/2018 09:12 PM, Waiman Long wrote: > > On 05/24/2018 06:28 AM, Juri Lelli wrote: > >> On 17/05/18 16:55, Waiman Long wrote: > >> > >> [...] > >> > >>> @@ -849,7 +860,12 @@ static void r

Re: [PATCH v8 4/6] cpuset: Make generate_sched_domains() recognize isolated_cpus

On 28/05/18 21:24, Waiman Long wrote: > On 05/28/2018 09:12 PM, Waiman Long wrote: > > On 05/24/2018 06:28 AM, Juri Lelli wrote: > >> On 17/05/18 16:55, Waiman Long wrote: > >> > >> [...] > >> > >>> @@ -849,7 +860,12 @@ static void r

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

Hi Vincent, On 25/05/18 15:12, Vincent Guittot wrote: > Now that we have both the dl class bandwidth requirement and the dl class > utilization, we can use the max of the 2 values when agregating the > utilization of the CPU. > > Signed-off-by: Vincent Guittot > ---

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

Hi Vincent, On 25/05/18 15:12, Vincent Guittot wrote: > Now that we have both the dl class bandwidth requirement and the dl class > utilization, we can use the max of the 2 values when agregating the > utilization of the CPU. > > Signed-off-by: Vincent Guittot > --- > kernel/sched/sched.h | 6

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 28/05/18 16:57, Vincent Guittot wrote: > Hi Juri, > > On 28 May 2018 at 12:12, Juri Lelli <juri.le...@redhat.com> wrote: > > Hi Vincent, > > > > On 25/05/18 15:12, Vincent Guittot wrote: > >> Now that we have both the dl class bandwidth requirement and

Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

On 28/05/18 16:57, Vincent Guittot wrote: > Hi Juri, > > On 28 May 2018 at 12:12, Juri Lelli wrote: > > Hi Vincent, > > > > On 25/05/18 15:12, Vincent Guittot wrote: > >> Now that we have both the dl class bandwidth requirement and the dl class > >

Re: [PATCH v5 08/10] cpufreq/schedutil: take into account interrupt

Hi Vincent, On 25/05/18 15:12, Vincent Guittot wrote: > The time spent under interrupt can be significant but it is not reflected > in the utilization of CPU when deciding to choose an OPP. Now that we have > access to this metric, schedutil can take it into account when selecting > the OPP for a

Re: [PATCH v5 08/10] cpufreq/schedutil: take into account interrupt

Hi Vincent, On 25/05/18 15:12, Vincent Guittot wrote: > The time spent under interrupt can be significant but it is not reflected > in the utilization of CPU when deciding to choose an OPP. Now that we have > access to this metric, schedutil can take it into account when selecting > the OPP for a

Re: [PATCH v5 08/10] cpufreq/schedutil: take into account interrupt

On 28/05/18 14:06, Vincent Guittot wrote: > Hi Juri, > > On 28 May 2018 at 12:41, Juri Lelli <juri.le...@redhat.com> wrote: > > Hi Vincent, > > > > On 25/05/18 15:12, Vincent Guittot wrote: > >> The time spent under interrupt can be significant but i

Re: [PATCH v5 08/10] cpufreq/schedutil: take into account interrupt

On 28/05/18 14:06, Vincent Guittot wrote: > Hi Juri, > > On 28 May 2018 at 12:41, Juri Lelli wrote: > > Hi Vincent, > > > > On 25/05/18 15:12, Vincent Guittot wrote: > >> The time spent under interrupt can be significant but it is not reflected > >

Re: [PATCH v8 4/6] cpuset: Make generate_sched_domains() recognize isolated_cpus

On 25/05/18 11:31, Patrick Bellasi wrote: [...] > Right, so the problem seems to be that we "need" to call > arch_update_cpu_topology() and we do that by calling > partition_sched_domains() which was initially introduced by: > >029190c515f1 ("cpuset sched_load_balance flag") > > back in

Re: [PATCH v8 4/6] cpuset: Make generate_sched_domains() recognize isolated_cpus

On 25/05/18 11:31, Patrick Bellasi wrote: [...] > Right, so the problem seems to be that we "need" to call > arch_update_cpu_topology() and we do that by calling > partition_sched_domains() which was initially introduced by: > >029190c515f1 ("cpuset sched_load_balance flag") > > back in

Re: [PATCH] kernel/sched/topology: Clarify root domain(s) debug string

On 25/05/18 13:35, Dietmar Eggemann wrote: [...] > > Looks good to me. Probably especially helpful when setting up exclusive > cpusets. > > Juno with big and little exclusive cpuset: > > ... > [ 124.231333] CPU1 attaching sched-domain(s): > [ 124.235482] domain-0: span=1-2 level=MC > [

Re: [PATCH] kernel/sched/topology: Clarify root domain(s) debug string

On 25/05/18 13:35, Dietmar Eggemann wrote: [...] > > Looks good to me. Probably especially helpful when setting up exclusive > cpusets. > > Juno with big and little exclusive cpuset: > > ... > [ 124.231333] CPU1 attaching sched-domain(s): > [ 124.235482] domain-0: span=1-2 level=MC > [

[tip:sched/core] sched/topology: Clarify root domain(s) debug string

Commit-ID: bf5015a50f1fdb248b48405b67cae24dc02605d6 Gitweb: https://git.kernel.org/tip/bf5015a50f1fdb248b48405b67cae24dc02605d6 Author: Juri Lelli <juri.le...@redhat.com> AuthorDate: Thu, 24 May 2018 17:29:36 +0200 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 25

[tip:sched/core] sched/topology: Clarify root domain(s) debug string

Commit-ID: bf5015a50f1fdb248b48405b67cae24dc02605d6 Gitweb: https://git.kernel.org/tip/bf5015a50f1fdb248b48405b67cae24dc02605d6 Author: Juri Lelli AuthorDate: Thu, 24 May 2018 17:29:36 +0200 Committer: Ingo Molnar CommitDate: Fri, 25 May 2018 08:03:38 +0200 sched/topology: Clarify

[PATCH] kernel/sched/topology: Clarify root domain(s) debug string

span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 } CPU1 attaching sched-domain(s): domain-0: span=0-5 level=MC groups: 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 }, 0:{ span=0 } [...] root domain span: 0-5 (max cpu_capacity = 1024) Signed-off-by:

[PATCH] kernel/sched/topology: Clarify root domain(s) debug string

span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 } CPU1 attaching sched-domain(s): domain-0: span=0-5 level=MC groups: 1:{ span=1 }, 2:{ span=2 }, 3:{ span=3 }, 4:{ span=4 }, 5:{ span=5 }, 0:{ span=0 } [...] root domain span: 0-5 (max cpu_capacity = 1024) Signed-off-by:

Re: [PATCH v8 3/6] cpuset: Add cpuset.sched.load_balance flag to v2

On 24/05/18 11:09, Waiman Long wrote: > On 05/24/2018 10:36 AM, Juri Lelli wrote: > > On 17/05/18 16:55, Waiman Long wrote: > > > > [...] > > > >> + A parent cgroup cannot distribute all its CPUs to child > >> + scheduling domain cgroups unless

Re: [PATCH v8 3/6] cpuset: Add cpuset.sched.load_balance flag to v2

On 24/05/18 11:09, Waiman Long wrote: > On 05/24/2018 10:36 AM, Juri Lelli wrote: > > On 17/05/18 16:55, Waiman Long wrote: > > > > [...] > > > >> + A parent cgroup cannot distribute all its CPUs to child > >> + scheduling domain cgroups unless

Re: [PATCH v8 3/6] cpuset: Add cpuset.sched.load_balance flag to v2

On 17/05/18 16:55, Waiman Long wrote: [...] > + A parent cgroup cannot distribute all its CPUs to child > + scheduling domain cgroups unless its load balancing flag is > + turned off. > + > + cpuset.sched.load_balance > + A read-write single value file which exists on non-root >

Re: [PATCH v8 3/6] cpuset: Add cpuset.sched.load_balance flag to v2

On 17/05/18 16:55, Waiman Long wrote: [...] > + A parent cgroup cannot distribute all its CPUs to child > + scheduling domain cgroups unless its load balancing flag is > + turned off. > + > + cpuset.sched.load_balance > + A read-write single value file which exists on non-root >

<    1   2   3   4   5   6   7   8   9   10   >