Hi Vincent,
Although I agree that moving the PELT code in a dedicated file is
probably the cleanest way to achieve what you want, I was wondering if
you were able no measure any overhead due to moving the __update_load_avg_*()
functions in a different translation unit ? This is introducing
On Tuesday 12 Dec 2017 at 12:21:39 (+0100), Vincent Guittot wrote:
> Hi Quentin,
>
> On 11 December 2017 at 15:08, Quentin Perret <quentin.per...@arm.com> wrote:
> > Hi Vincent,
> >
> > Although I agree that moving the PELT code in a dedicated file is
> > pr
On Tuesday 08 May 2018 at 15:15:26 (+0530), Viresh Kumar wrote:
> On 08-05-18, 11:09, Dietmar Eggemann wrote:
> > This would make sure that the kthreads are bound to the correct set of cpus
> > for platforms with those cpufreq drivers (cpufreq-dt (h960), scmi-cpufreq,
> > scpi-cpufreq) but it will
On Tuesday 08 May 2018 at 11:09:57 (+0200), Dietmar Eggemann wrote:
> On 05/08/2018 10:22 AM, Viresh Kumar wrote:
> > On 08-05-18, 08:33, Dietmar Eggemann wrote:
> > > This reverts commit e2cabe48c20efb174ce0c01190f8b9c5f3ea1d13.
> > >
> > > Lifting the restriction that the sugov kthread is bound
Hi Dietmar,
On Friday 27 Apr 2018 at 10:30:39 (+0200), Dietmar Eggemann wrote:
> Hi Viresh,
>
> On 04/26/2018 12:30 PM, Viresh Kumar wrote:
> > Call sync_entity_load_avg() directly from find_idlest_cpu() instead of
> > select_task_rq_fair(), as that's where we need to use task's utilization
> >
On Tuesday 08 May 2018 at 16:04:27 (+0530), Viresh Kumar wrote:
> On 08-05-18, 11:02, Quentin Perret wrote:
> > The sugov kthreads are DL tasks so they're not impacted by EAS. But even
> > if you take EAS out of the picture, those kthreads are assigned to a
> > "random&
On Tuesday 08 May 2018 at 16:44:51 (+0530), Viresh Kumar wrote:
> On 08-05-18, 12:00, Quentin Perret wrote:
> > Right, I see your point. Now, with the current implementation, why should
> > we randomly force a CPU to manage the kthread of another ? IIUC deadline
> > shoul
duplication. The new map_util_freq() function is inlined to avoid
overheads.
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Signed-off-by: Quentin Perret <quentin.per...@arm.com>
---
include/linux/sched/cpufreq.h| 6 ++
kernel/sched/cpufreq_sche
as a
convenient way of exposing data to sysfs. However, it could also be
used in the future to allocate and release frequency domains in a more
dynamic way using reference counting.
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: "Rafael J. Wysocki" <r...@rjwysocki.net>
Signed-
by constant
propagation.
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Signed-off-by: Quentin Perret <quentin.per...@arm.com>
---
kernel/sched/sched.h| 27 ++
kernel/sched/topology.c | 113
2
. Cross-sockets wake-up balancing will only happen when the
system is over-utilized, or this_cpu and prev_cpu are in different
sockets.
cc: Ingo Molnar <mi...@redhat.com>
cc: Peter Zijlstra <pet...@infradead.org>
Suggested-by: Morten Rasmussen <morten.rasmus...@arm.com>
Signed-off-
Peter Zijlstra <pet...@infradead.org>
Signed-off-by: Quentin Perret <quentin.per...@arm.com>
---
include/linux/sched/topology.h | 19 +++
kernel/sched/sched.h | 18 --
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/i
smussen (1):
sched: Add over-utilization/tipping point indicator
Quentin Perret (9):
sched: Relocate arch_scale_cpu_capacity
sched/cpufreq: Factor out utilization to frequency mapping
PM: Introduce an Energy Model management framework
PM / EM: Expose the Energy Model in sysfs
sched
the consumption of each online CPU according to its Energy Model
and its percentage of busy time.
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Signed-off-by: Quentin Perret <quentin.per...@arm.com>
---
kernel/
disabled.
This commit fixes this issue by re-building the scheduling domain from the
arch topology driver, once CPUfreq is up and running and when the capacity
of the CPUs have been updated to their final value.
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Signed-off-by: Quentin
adead.org>
Signed-off-by: Morten Rasmussen <morten.rasmus...@arm.com>
Signed-off-by: Quentin Perret <quentin.per...@arm.com>
---
kernel/sched/fair.c | 47 +---
kernel/sched/sched.h | 3 +++
2 files changed, 47 insertions(+), 3 deletions(-)
el J. Wysocki" <r...@rjwysocki.net>
Signed-off-by: Quentin Perret <quentin.per...@arm.com>
---
include/linux/energy_model.h | 122 +
kernel/power/Kconfig | 15 +++
kernel/power/Makefile| 2 +
kernel/power/energy_model.c | 249 +++
(CONFIG_ENERGY_MODEL for ex.) at compile time,
sched_enegy_enabled() defaults to a constant "false" value, hence
letting the compiler remove the unused EAS code entirely.
Cc: Ingo Molnar <mi...@redhat.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Signed-off-by: Quentin Perret &
Hi Vincent,
On Friday 25 May 2018 at 15:12:22 (+0200), Vincent Guittot wrote:
> We want to track rt_rq's utilization as a part of the estimation of the
> whole rq's utilization. This is necessary because rt tasks can steal
> utilization to cfs tasks and make them lighter than they are.
> As we
On Wednesday 06 Jun 2018 at 11:59:04 (+0200), Vincent Guittot wrote:
> On 6 June 2018 at 11:44, Quentin Perret wrote:
> > On Tuesday 05 Jun 2018 at 16:18:09 (+0200), Peter Zijlstra wrote:
> >> On Mon, Jun 04, 2018 at 08:08:58PM +0200, Vincent Guittot wrote:
> >> >
On Tuesday 05 Jun 2018 at 16:18:09 (+0200), Peter Zijlstra wrote:
> On Mon, Jun 04, 2018 at 08:08:58PM +0200, Vincent Guittot wrote:
> > On 4 June 2018 at 18:50, Peter Zijlstra wrote:
>
> > > So this patch-set tracks the !cfs occupation using the same function,
> > > which is all good. But what,
Hi Claudio,
On Wednesday 06 Jun 2018 at 15:05:58 (+0200), Claudio Scordino wrote:
> Hi Quentin,
>
> Il 05/06/2018 16:13, Juri Lelli ha scritto:
> > On 05/06/18 15:01, Quentin Perret wrote:
> > > On Tuesday 05 Jun 2018 at 15:15:18 (+0200), Juri Lelli wrote:
> >
on an idle little CPU will be given ~512 of util_avg,
even if the CPU's capacity is significantly less than that.
Fix this by computing the spare capacity with arch_scale_cpu_capacity().
Cc: Ingo Molnar
Cc: Peter Zijlstra
Acked-by: Vincent Guittot
Signed-off-by: Quentin Perret
---
v2: added
On Tuesday 12 Jun 2018 at 11:16:56 (+0200), 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
>
On Friday 08 Jun 2018 at 13:59:28 (+0200), Juri Lelli wrote:
> 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:
> >
On Friday 08 Jun 2018 at 18:39:56 (+0200), Dietmar Eggemann wrote:
> On 06/08/2018 03:11 PM, Quentin Perret wrote:
> > On Friday 08 Jun 2018 at 14:39:33 (+0200), Dietmar Eggemann wrote:
>
> [...]
>
> > > > > Even though we would be forced to get cpufreq's related
Hi Javi,
On Friday 08 Jun 2018 at 14:39:42 (+0100), Javi Merino wrote:
> On Wed, Jun 06, 2018 at 05:26:47PM +0100, Quentin Perret wrote:
> > On Wednesday 06 Jun 2018 at 16:29:50 (+0100), Quentin Perret wrote:
> > > On Wednesday 06 Jun 2018 at 17:20:00 (+0200)
On Friday 08 Jun 2018 at 14:39:33 (+0200), Dietmar Eggemann wrote:
> In your current '(3)* Arm/Arm64 init code' (* see at the end of this email)
> you have this dev_pm_opp_of_estimate_power() em_data_callback active_power
> function.
>
> Let's say thermal and the task scheduler would initialize
Hi Dietmar,
On Thursday 07 Jun 2018 at 17:55:32 (+0200), Dietmar Eggemann wrote:
> On 06/07/2018 05:19 PM, 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:
>
On Friday 08 Jun 2018 at 11:36:13 (+0200), Juri Lelli wrote:
> 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
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 *p, int prev_cpu)
> > +{
> > + unsigned long cur_energy, prev_ene
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 (EM) of the platform. This commit extends the scheduler topology
> &
Hi Juri,
On Thursday 07 Jun 2018 at 16:44:09 (+0200), Juri Lelli wrote:
> 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,
On Thursday 07 Jun 2018 at 18:04:19 (+0200), Juri Lelli wrote:
> On 07/06/18 16:19, Quentin Perret wrote:
> > On Thursday 07 Jun 2018 at 16:44:09 (+0200), Juri Lelli wrote:
> > > > + if (!fd->cs_table)
> > > > + goto free_fd;
> &
On Thursday 07 Jun 2018 at 18:29:10 (+0200), Juri Lelli wrote:
> On 07/06/18 17:02, Quentin Perret wrote:
> > On Thursday 07 Jun 2018 at 16:44:22 (+0200), Juri Lelli wrote:
> > > Not sure about this. How about multi-freq domain same max capacity
> > > systems. I underst
On Thursday 14 Jun 2018 at 15:50:40 (+0200), Juri Lelli wrote:
> 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:
> > > >
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()
> > does _not_ take the hotplug lock before calling partition_sched_domains()
&
Hi Pavan,
On Tuesday 19 Jun 2018 at 14:48:41 (+0530), Pavan Kondeti wrote:
> On Mon, May 21, 2018 at 03:25:05PM +0100, Quentin Perret wrote:
>
>
>
> > +static void start_eas_workfn(struct work_struct *work);
> > +static DECLARE_WORK(start_eas_work, start_eas_workfn
On Tuesday 19 Jun 2018 at 18:20:42 (+0200), Peter Zijlstra wrote:
> Right, so I would not do that many things at once. Also be more explicit
> about what data structure, and why.
OK, I can probably split that patch in two smaller patches. One that
introduces and enables the static_key (or
On Thursday 14 Jun 2018 at 16:30:37 (+0200), Juri Lelli wrote:
> 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:
> > >
> > > [...]
> > >
>
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
> ---
> kernel/sched/cpufreq_schedutil.c | 14 +++---
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 CPU.
>
> Signed-off-by: Vincent Guittot
> ---
>
On Friday 25 May 2018 at 18:14:23 (+0200), Peter Zijlstra wrote:
> On Fri, May 25, 2018 at 03:26:48PM +0100, Quentin Perret wrote:
> > (both quite old TBH -- 4.9.4 for arm64, 4.8.4 for x86).
>
> You really should try with a more recent compiler.
Right, so I just gave it a try f
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:
> > > Now that we have both the dl class bandwidth requirement and the
On Friday 01 Jun 2018 at 18:23:59 (+0100), Patrick Bellasi wrote:
> On 01-Jun 18:23, Peter Zijlstra wrote:
> > On Thu, May 31, 2018 at 10:46:07AM +0200, Juri Lelli wrote:
> > > On 30/05/18 17:46, Quentin Perret wrote:
> >
> > > > So I understand why we wa
on an idle little CPU will be given ~512 of util_avg,
even if the CPU's capacity is significantly less than that.
Fix this by computing the spare capacity with arch_scale_cpu_capacity().
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Quentin Perret
---
kernel/sched/fair.c | 10 ++
1
On Monday 04 Jun 2018 at 14:23:42 (+0200), Vincent Guittot wrote:
> On 4 June 2018 at 13:58, Quentin Perret wrote:
> > When a new task wakes-up for the first time, its initial utilization
> > is set to half of the spare capacity of its CPU. The current
>
Hi,
The main new feature of this patch-set is the Energy Model framework we
discussed at OSPM. The core of it and the APIs are all implemented in
patch 03/10, so this is really where I was hoping to get some feedback.
Is the overall idea of this framework reasonable ? What do you think
about the
Hi Vincent,
On Tuesday 05 Jun 2018 at 10:36:26 (+0200), Vincent Guittot wrote:
> Hi Quentin,
>
> On 25 May 2018 at 15:12, Vincent Guittot wrote:
> > This patchset initially tracked only the utilization of RT rq. During
> > OSPM summit, it has been discussed the opportunity to extend it in order
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 to show the idea) applied
> > on tip/sched/core ?
> >
> &
On Tuesday 05 Jun 2018 at 13:59:56 (+0200), Vincent Guittot wrote:
> On 5 June 2018 at 12:57, Quentin Perret wrote:
> > Hi Vincent,
> >
> > On Tuesday 05 Jun 2018 at 10:36:26 (+0200), Vincent Guittot wrote:
> >> Hi Quentin,
> >>
> >> On 25
On Tuesday 05 Jun 2018 at 15:18:38 (+0200), Vincent Guittot wrote:
> On 5 June 2018 at 15:12, Quentin Perret wrote:
> > On Tuesday 05 Jun 2018 at 13:59:56 (+0200), Vincent Guittot wrote:
> >> On 5 June 2018 at 12:57, Quentin Perret wrote:
> >> > Hi Vincent,
> &
On Tuesday 05 Jun 2018 at 15:09:54 (+0100), Quentin Perret wrote:
> On Tuesday 05 Jun 2018 at 15:55:43 (+0200), Vincent Guittot wrote:
> > On 5 June 2018 at 15:52, Quentin Perret wrote:
> > > On Tuesday 05 Jun 2018 at 15:18:38 (+0200), Vincent Guittot wrote:
> > &g
On Tuesday 05 Jun 2018 at 15:55:43 (+0200), Vincent Guittot wrote:
> On 5 June 2018 at 15:52, Quentin Perret wrote:
> > On Tuesday 05 Jun 2018 at 15:18:38 (+0200), Vincent Guittot wrote:
> >> On 5 June 2018 at 15:12, Quentin Perret wrote:
> >> I would say no bec
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,
> > >
> > > On 05/06/18 11:57, 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 max_cap_state = cs_table->nr_cap_states - 1;
> > +
On Wednesday 06 Jun 2018 at 16:29:50 (+0100), Quentin Perret wrote:
> On Wednesday 06 Jun 2018 at 17:20:00 (+0200), Juri Lelli wrote:
> > > > This brings me to another question. Let's say there are multiple users
> > > > of
> > > > the Energy Model in the s
On Wednesday 06 Jun 2018 at 17:20:00 (+0200), Juri Lelli wrote:
> > > This brings me to another question. Let's say there are multiple users of
> > > the Energy Model in the system. Shouldn't the units of frequency and power
> > > not standardized, maybe Mhz and mW?
> > > The task scheduler
On Wednesday 06 Jun 2018 at 15:53:27 (+0200), Claudio Scordino wrote:
> Hi Quentin,
>
> 2018-06-06 15:20 GMT+02:00 Quentin Perret :
> >
> > Hi Claudio,
> >
> > On Wednesday 06 Jun 2018 at 15:05:58 (+0200), Claudio Scordino wrote:
> > > Hi Quentin,
>
On Wednesday 06 Jun 2018 at 18:47:34 (+0200), Juri Lelli wrote:
> Hi Quentin,
>
> On 21/05/18 15:24, Quentin Perret wrote:
>
> [...]
>
> > +#ifdef CONFIG_ENERGY_MODEL
>
> [...]
>
> > +struct em_data_callback {
> > + /**
> > +* active
Hi Luca,
On Wednesday 06 Jun 2018 at 23:05:36 (+0200), luca abeni wrote:
> Hi,
>
> On Wed, 6 Jun 2018 14:20:46 +0100
> Quentin Perret wrote:
> [...]
> > > However, IMHO, these are corner cases and in the average case it is
> > > better to rely on runnin
On Friday 25 May 2018 at 19:04:55 (+0100), Patrick Bellasi wrote:
> On 25-May 15:26, Quentin Perret wrote:
> > And also, I understand these functions are large, but if we _really_
> > want to inline them even though they're big, why not putting them in
> > sched-pelt.h ?
>
On Tuesday 29 May 2018 at 17:02:29 (+0200), Vincent Guittot wrote:
> Hi Quentin,
>
> On 29 May 2018 at 16:55, Quentin Perret wrote:
> >
> > On Friday 25 May 2018 at 19:04:55 (+0100), Patrick Bellasi wrote:
> > > On 25-May 15:26, Quentin Perret wrote:
On Monday 04 Jun 2018 at 18:50:47 (+0200), Peter Zijlstra wrote:
> On Fri, May 25, 2018 at 03:12:21PM +0200, Vincent Guittot wrote:
> > When both cfs and rt tasks compete to run on a CPU, we can see some
> > frequency
> > drops with schedutil governor. In such case, the cfs_rq's utilization
> >
On Tuesday 19 Jun 2018 at 14:26:32 (+0200), Peter Zijlstra wrote:
> On Mon, May 21, 2018 at 03:25:00PM +0100, 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
&
On Tuesday 19 Jun 2018 at 15:23:38 (+0200), Peter Zijlstra wrote:
> On Tue, Jun 19, 2018 at 01:58:58PM +0100, Quentin Perret wrote:
> > On Tuesday 19 Jun 2018 at 13:34:08 (+0200), Peter Zijlstra wrote:
> > > On Mon, May 21, 2018 at 03:24:58PM +0100, Quentin Perret wrot
On Tuesday 19 Jun 2018 at 13:34:08 (+0200), Peter Zijlstra wrote:
> On Mon, May 21, 2018 at 03:24:58PM +0100, Quentin Perret wrote:
> > +struct em_freq_domain *em_cpu_get(int cpu)
> > +{
> > + struct em_freq_domain *fd;
> > + unsigned long flags;
> > +
>
On Tuesday 19 Jun 2018 at 14:16:43 (+0200), Peter Zijlstra wrote:
> On Mon, May 21, 2018 at 03:24:59PM +0100, Quentin Perret wrote:
> > This exposes the Energy Model (read-only) of all frequency domains in
> > sysfs for convenience. To do so, a parent kobject is added to the CP
On Tuesday 19 Jun 2018 at 16:16:42 (+0200), Peter Zijlstra wrote:
> On Tue, Jun 19, 2018 at 02:38:45PM +0100, Quentin Perret wrote:
> > But maybe I could use something simpler than a lock in this case ?
> > Would WRITE_ONCE/READ_ONCE be enough to ensure that atomicity for
> &g
On Tuesday 19 Jun 2018 at 20:42:50 (+0200), Peter Zijlstra wrote:
> On Tue, Jun 19, 2018 at 06:13:17PM +0100, Quentin Perret wrote:
> > Would replacing the static_key by a flag attached to the root_domain be
> > reasonable ?
>
> Keep the static key as is, enable if any root
Hi Sudeep,
On Monday 12 Feb 2018 at 18:45:23 (+), Sudeep Holla wrote:
[...]
> +/*
> + * perf_ops->freq_set is not a synchronous, the actual OPP change will
> + * happen asynchronously and can get notified if the events are
> + * subscribed for by the SCMI firmware
> + */
> +static int
>
Hi Morten,
On Friday 16 Feb 2018 at 15:41:01 (+), Morten Rasmussen wrote:
> On Fri, Feb 16, 2018 at 02:47:04PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 15, 2018 at 04:20:48PM +, Morten Rasmussen wrote:
> > > +static void update_asym_cpucapacity(int cpu)
> > > +{
> > > + if
Hi Pavan,
On Tuesday 19 Jun 2018 at 10:36:01 (+0530), Pavan Kondeti wrote:
> On Mon, May 21, 2018 at 03:25:04PM +0100, Quentin Perret wrote:
>
>
>
> > + if (cpumask_test_cpu(prev_cpu, >cpus_allowed))
> > + prev_energy = best_energy = compute_energy
On Tuesday 19 Jun 2018 at 13:07:34 (+0200), Peter Zijlstra wrote:
> On Mon, May 21, 2018 at 03:24:58PM +0100, Quentin Perret wrote:
> > +struct em_freq_domain {
> > + struct em_cs_table *cs_table;
> > + cpumask_t cpus;
> > +};
>
> https://lkml
On Tuesday 19 Jun 2018 at 15:21:40 (+0530), Pavan Kondeti wrote:
> On Mon, May 21, 2018 at 03:25:02PM +0100, Quentin Perret wrote:
>
>
>
> >
> > +/*
> > + * Returns the util of "cpu" if "p" wakes up on "dst_cpu".
> > + */
>
On Tuesday 19 Jun 2018 at 12:31:08 (+0200), Juri Lelli wrote:
> On 19/06/18 11:25, Quentin Perret wrote:
> > On Tuesday 19 Jun 2018 at 12:19:01 (+0200), Juri Lelli wrote:
> > > On 19/06/18 11:02, Quentin Perret wrote:
> > > > On Tuesday 19 Jun 2018 at 11:4
On Tuesday 19 Jun 2018 at 11:47:14 (+0200), Juri Lelli wrote:
> On 19/06/18 10:40, Quentin Perret wrote:
> > Hi Pavan,
> >
> > On Tuesday 19 Jun 2018 at 14:48:41 (+0530), Pavan Kondeti wrote:
>
> [...]
>
> > > There seems to be a sysfs interface exposed by
On Tuesday 19 Jun 2018 at 12:19:01 (+0200), Juri Lelli wrote:
> On 19/06/18 11:02, Quentin Perret wrote:
> > On Tuesday 19 Jun 2018 at 11:47:14 (+0200), Juri Lelli wrote:
> > > On 19/06/18 10:40, Quentin Perret wrote:
> > > > Hi Pavan,
> > > >
> &g
On Tuesday 19 Jun 2018 at 13:31:06 (+0200), Peter Zijlstra wrote:
> On Mon, May 21, 2018 at 03:24:58PM +0100, Quentin Perret wrote:
> > + read_lock_irqsave(_data_lock, flags);
> > + for_each_cpu(cpu, cpu_possible_mask) {
>
> I know we're likely to only use
Hi Peter,
On Thursday 21 Jun 2018 at 20:45:24 (+0200), Peter Zijlstra wrote:
> On Fri, Jun 08, 2018 at 02:09:47PM +0200, Vincent Guittot wrote:
> > static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
> > {
> > struct rq *rq = cpu_rq(sg_cpu->cpu);
> > + unsigned long util;
Hi Morten,
On Wednesday 20 Jun 2018 at 10:05:41 (+0100), Morten Rasmussen wrote:
> +static void update_asym_cpucapacity(int cpu)
> +{
> + int enable = false;
> +
> + rcu_read_lock();
> + if (lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY))
> + enable = true;
> +
On Thursday 02 Aug 2018 at 14:45:11 (+0200), Peter Zijlstra wrote:
> On Thu, Aug 02, 2018 at 02:33:15PM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 30, 2018 at 12:35:27PM -0700, skan...@codeaurora.org wrote:
> > > On 2018-07-24 05:25, Quentin Perret wrote:
> > > If i
On Thursday 02 Aug 2018 at 15:04:40 (+0200), Peter Zijlstra wrote:
> On Wed, Aug 01, 2018 at 10:23:27AM +0100, Quentin Perret wrote:
> > On Wednesday 01 Aug 2018 at 10:35:32 (+0200), Rafael J. Wysocki wrote:
> > > On Wed, Aug 1, 2018 at 10:23 AM, Quentin Perret
> > >
On Thursday 02 Aug 2018 at 15:54:26 (+0200), Peter Zijlstra wrote:
> On Tue, Jul 24, 2018 at 01:25:19PM +0100, Quentin Perret wrote:
> > @@ -6385,18 +6492,26 @@ static int
> > select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag, int
> > wake_flags)
On Thursday 02 Aug 2018 at 17:14:15 (+0200), Vincent Guittot wrote:
> On Thu, 2 Aug 2018 at 16:14, Quentin Perret wrote:
> > Good point, setting the util_avg to 0 for new tasks should help
> > filtering out those tiny tasks too. And that would match with the idea
> > o
On Thursday 02 Aug 2018 at 18:07:49 (+0200), Vincent Guittot wrote:
> On Thu, 2 Aug 2018 at 18:00, Quentin Perret wrote:
> >
> > On Thursday 02 Aug 2018 at 17:55:24 (+0200), Vincent Guittot wrote:
> > > On Thu, 2 Aug 2018 at 17:30, Quentin Perret
> > > wrote:
&
On Thursday 02 Aug 2018 at 17:55:24 (+0200), Vincent Guittot wrote:
> On Thu, 2 Aug 2018 at 17:30, Quentin Perret wrote:
> >
> > On Thursday 02 Aug 2018 at 17:14:15 (+0200), Vincent Guittot wrote:
> > > On Thu, 2 Aug 2018 at 16:14, Quentin Perret
> > > w
On Thursday 02 Aug 2018 at 18:38:01 (+0200), Vincent Guittot wrote:
> On Thu, 2 Aug 2018 at 18:10, Quentin Perret wrote:
> >
> > On Thursday 02 Aug 2018 at 18:07:49 (+0200), Vincent Guittot wrote:
> > > On Thu, 2 Aug 2018 at 18:00, Quentin Perret
> > > wrote:
&
On Friday 03 Aug 2018 at 09:48:47 (+0200), Vincent Guittot wrote:
> On Thu, 2 Aug 2018 at 18:59, Quentin Perret wrote:
> I'm not really concerned about re-enabling load balance but more that
> the effort of packing of tasks in few cpus/clusters that EAS tries to
> do can be broken f
On Thursday 02 Aug 2018 at 19:36:01 (+0200), Peter Zijlstra wrote:
> Using a !schedutil governor doesn't even get us that and we're basically
> running on random input without any feedback to close the loop. Not
> something I feel we should support or care for.
Fair enough, supporting users using
On Thursday 02 Aug 2018 at 16:39:18 (+0100), Quentin Perret wrote:
> Sounds good :-) Would kernel/sched/pelt.c be the right place then ? It's
> cross-class and kinda pelt-related I guess
Since we agreed to create a dependency between EAS and sugov, I don't think
there is a lot of
On Friday 03 Aug 2018 at 15:49:24 (+0200), Vincent Guittot wrote:
> On Fri, 3 Aug 2018 at 10:18, Quentin Perret wrote:
> >
> > On Friday 03 Aug 2018 at 09:48:47 (+0200), Vincent Guittot wrote:
> > > On Thu, 2 Aug 2018 at 18:59, Quentin Perret
> > > wrote:
> &
Hi Vincent,
On Monday 30 Jul 2018 at 17:53:23 (+0200), Vincent Guittot wrote:
[...]
> ok, so you copy/paste what is done in cpu cooling device ?
>
> Nevertheless I still have some concerns with the formula used here and
> in cpu cooling device:
>
>
On Thursday 26 Jul 2018 at 17:00:50 (+0100), Valentin Schneider wrote:
> > +DECLARE_PER_CPU(struct sched_domain *, sd_ea);
>
> There's already the asym-packing shortcut which is making naming a bit more
> tedious, but should that really be named energy-aware? IMO it's just the
> lowest level at
On Thursday 26 Jul 2018 at 17:39:19 (-0700), Joel Fernandes wrote:
> On Tue, Jul 24, 2018 at 06:29:02AM -0700, Tejun Heo wrote:
> > Hello, Patrick.
> >
> > On Mon, Jul 23, 2018 at 06:22:15PM +0100, Patrick Bellasi wrote:
> > > However, the "best effort" bandwidth control we have for CFS and RT
>
On Wednesday 01 Aug 2018 at 09:32:49 (+0200), Rafael J. Wysocki wrote:
> On Tue, Jul 31, 2018 at 9:31 PM, wrote:
> > On 2018-07-31 00:59, Quentin Perret wrote:
> >>
> >> On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org wrote:
> >
On Wednesday 01 Aug 2018 at 10:35:32 (+0200), Rafael J. Wysocki wrote:
> On Wed, Aug 1, 2018 at 10:23 AM, Quentin Perret
> wrote:
> > On Wednesday 01 Aug 2018 at 09:32:49 (+0200), Rafael J. Wysocki wrote:
> >> On Tue, Jul 31, 2018 at 9:31 PM, wrote:
> >> >&g
On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org wrote:
[...]
> If it's going to be a different aggregation from what's done for frequency
> guidance, I don't see the point of having this inside schedutil. Why not
> keep it inside the scheduler files?
This code basically results
On Thursday 02 Aug 2018 at 15:48:01 (+0200), Vincent Guittot wrote:
> On Thu, 2 Aug 2018 at 15:19, Quentin Perret wrote:
> >
> > On Thursday 02 Aug 2018 at 15:08:01 (+0200), Peter Zijlstra wrote:
> > > On Thu, Aug 02, 2018 at 02:03:38PM +0100, Quentin Perret wrote:
> &g
On Thursday 02 Aug 2018 at 14:26:29 (+0200), Peter Zijlstra wrote:
> On Tue, Jul 24, 2018 at 01:25:16PM +0100, Quentin Perret wrote:
> > @@ -5100,8 +5118,17 @@ enqueue_task_fair(struct rq *rq, struct task_struct
> > *p, int flags)
> >
1 - 100 of 1349 matches
Mail list logo
