On 19/03/13 10:28, Will Deacon wrote:
On Tue, Mar 19, 2013 at 06:39:38AM +, Santosh Shilimkar wrote:
On Monday 18 March 2013 10:36 PM, Will Deacon wrote:
Any chance you could follow up with your firmware/hardware guys about this
please? I'd really like to understand how we end up in this
that check back to avoid the mentioned issue.
Cc: Dietmar Eggemann dietmar.eggem...@arm.com
Cc: Will Deacon will.dea...@arm.com
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/kernel
3df278ad50690a7878c9cc6b18e226805e1f4bd1 Mon Sep 17 00:00:00 2001
From: Dietmar Eggemann dietmar.eggem...@arm.com
Date: Tue, 12 Nov 2013 12:37:36 +
Subject: [PATCH] sched: rework sched_domain setup code
This patch removes the sched_domain initializer macros
SD_[SIBLING|MC|BOOK|CPU]_INIT in core.c
On 12/11/13 18:08, Peter Zijlstra wrote:
On Tue, Nov 12, 2013 at 05:43:36PM +, Dietmar Eggemann wrote:
This patch removes the sched_domain initializer macros
SD_[SIBLING|MC|BOOK|CPU]_INIT in core.c and in archs and replaces them
with calls to the new function sd_init(). The function
On 12/03/14 13:47, Vincent Guittot wrote:
On 12 March 2014 14:28, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 11/03/14 13:17, Peter Zijlstra wrote:
On Sat, Mar 08, 2014 at 12:40:58PM +, Dietmar Eggemann wrote:
I don't have a strong opinion about using or not a cpu argument
From: Dietmar Eggemann dietmar.eggem...@arm.com
The struct sched_avg of struct rq is only used in case group
scheduling is enabled inside __update_tg_runnable_avg() to update
per-cpu representation of a task group. I.e. that there is no need to
maintain the runnable avg of a rq
On 25/02/14 13:16, Srikar Dronamraju wrote:
The struct sched_avg of struct rq is only used in case group
scheduling is enabled inside __update_tg_runnable_avg() to update
per-cpu representation of a task group. I.e. that there is no need to
maintain the runnable avg of a rq in the
On 25/02/14 20:52, Peter Zijlstra wrote:
On Tue, Feb 25, 2014 at 11:47:42AM +, Dietmar Eggemann wrote:
+++ b/kernel/sched/sched.h
@@ -630,7 +630,9 @@ struct rq {
struct llist_head wake_list;
#endif
+#ifdef CONFIG_FAIR_GROUP_SCHED
struct sched_avg avg;
+#endif
On 05/03/14 07:18, Vincent Guittot wrote:
We replace the old way to configure the scheduler topology with a new method
which enables a platform to declare additionnal level (if needed).
We still have a default topology table definition that can be used by platform
that don't want more level
On 05/03/14 07:18, Vincent Guittot wrote:
Create a dedicated topology table for ARM which will create new level to
differentiate CPUs that can or not powergate independantly from others.
The patch gives an example of how to add domain that will take advantage of
SD_SHARE_POWERDOMAIN.
On 05/03/14 07:18, Vincent Guittot wrote:
This patchset was previously part of the larger tasks packing patchset [1].
I have splitted the latter in 3 different patchsets (at least) to make the
thing easier.
-configuration of sched_domain topology (this patchset)
-update and consolidation of
On 06/03/14 09:04, Vincent Guittot wrote:
On 6 March 2014 07:17, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 05/03/14 07:18, Vincent Guittot wrote:
This patchset was previously part of the larger tasks packing patchset
[1].
I have splitted the latter in 3 different patchsets (at least
On 07/03/14 02:47, Vincent Guittot wrote:
On 6 March 2014 20:31, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 06/03/14 09:04, Vincent Guittot wrote:
On 6 March 2014 07:17, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 05/03/14 07:18, Vincent Guittot wrote:
This patchset
On 11/03/14 13:27, Vincent Guittot wrote:
On 11 March 2014 11:31, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Mar 06, 2014 at 04:32:35PM +0800, Vincent Guittot wrote:
Never got the new name DIE for CPU? Might confuse people when they use
/proc/sys/kernel/sched_domain/cpuX/domainY/name
On 12/03/14 07:44, Vincent Guittot wrote:
On 12 March 2014 05:42, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
On 03/11/2014 06:48 PM, Vincent Guittot wrote:
On 11 March 2014 11:08, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
Hi Vincent,
On 03/05/2014 12:48 PM, Vincent Guittot
On 11/03/14 13:17, Peter Zijlstra wrote:
On Sat, Mar 08, 2014 at 12:40:58PM +, Dietmar Eggemann wrote:
I don't have a strong opinion about using or not a cpu argument for
setting the flags of a level (it was part of the initial proposal
before we start to completely rework the build
On 18/03/14 17:56, Vincent Guittot wrote:
We replace the old way to configure the scheduler topology with a new method
which enables a platform to declare additionnal level (if needed).
We still have a default topology table definition that can be used by platform
that don't want more level
On 19/03/14 12:41, Peter Zijlstra wrote:
The keyboard deity gave us delete, please apply graciously when replying
to large emails.
Sorry about that, will do next time.
On Wed, Mar 19, 2014 at 11:27:12AM +, Dietmar Eggemann wrote:
On 18/03/14 17:56, Vincent Guittot wrote
On 19/03/14 13:33, Vincent Guittot wrote:
[...]
Is there a way to check that MC and GMC have to have
SD_SHARE_PKG_RESOURCES set so that this can't happen unnoticed?
So from the core codes perspective those names mean less than nothing.
Its just a string to carry along for us meat-bags. The
On 17/03/14 11:52, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at 01:28:07PM +, Dietmar Eggemann wrote:
[...]
By making it robust, I guess you mean that the core scheduler has to
check that the provided set-ups are sane, something like the following
code snippet in sd_init()
if (WARN_ONCE
On 19/03/14 16:22, Vincent Guittot wrote:
We replace the old way to configure the scheduler topology with a new method
which enables a platform to declare additionnal level (if needed).
We still have a default topology table definition that can be used by platform
that don't want more level
On 20/03/14 17:02, Vincent Guittot wrote:
On 20 March 2014 13:41, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 19/03/14 16:22, Vincent Guittot wrote:
We replace the old way to configure the scheduler topology with a new method
which enables a platform to declare additionnal level
[...]
Firstly, we need to scale cpu power in update_cpu_power() regarding
uArch, frequency and rt/irq pressure.
Here the freq related value we get back from arch_scale_freq_power(...,
cpu) could be an instantaneous value (curr_freq(cpu)/max_freq(cpu)).
Secondly, to be able to scale the
... turned out that probably the cc list was too big for lkml. Dropping
all the individual email addresses on CC.
... it seems that this message hasn't made it to the list. Apologies to
everyone on To: and Cc: receiving it again.
On 03/06/14 13:14, Peter Zijlstra wrote:
On Fri, May 30, 2014 at
On 09/06/14 22:18, Yuyang Du wrote:
On Mon, Jun 09, 2014 at 06:56:17PM +0100, Dietmar Eggemann wrote:
Thanks, Dietmar.
I'm running these patches on my ARM TC2 on top of
kernel/git/torvalds/linux.git (v3.15-rc7-79-gfe45736f4134). There're
considerable changes in the area of sched domain
On 10/06/14 19:09, Yuyang Du wrote:
On Tue, Jun 10, 2014 at 12:52:06PM +0100, Dietmar Eggemann wrote:
Hi Dietmar,
Not in this sense but there is no functionality in the scheduler right
now to check constantly if an sd flag has been set/unset via sysctl.
Sorry, I still don't understand
On 23/05/14 16:53, Vincent Guittot wrote:
Monitor the activity level of each group of each sched_domain level. The
activity is the amount of cpu_power that is currently used on a CPU or group
of CPUs. We use the runnable_avg_sum and _period to evaluate this activity
level. In the special use
On 23/05/14 16:53, Vincent Guittot wrote:
If the CPU is used for handling lot of IRQs, trig a load balance to check if
it's worth moving its tasks on another CPU that has more capacity
Signed-off-by: Vincent Guittot vincent.guit...@linaro.org
---
kernel/sched/fair.c | 13 +
1
On 23/05/14 16:52, Vincent Guittot wrote:
power_orig is only changed for system with a SMT sched_domain level in order
to
reflect the lower capacity of CPUs. Heterogenous system also have to reflect
an
original capacity that is different from the default value.
Create a more generic
On 30/05/14 20:20, Vincent Guittot wrote:
On 30 May 2014 11:50, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 23/05/14 16:53, Vincent Guittot wrote:
Monitor the activity level of each group of each sched_domain level. The
activity is the amount of cpu_power that is currently used
Hi Vincent Peter,
On 28/05/14 07:49, Vincent Guittot wrote:
[...]
Nick,
While doing some rework on the wake affine part of the scheduler, i
failed to catch the use case that takes advantage of a condition that
you added some while ago with the commit
Hi Peter,
On 30/04/14 14:39, Dietmar Eggemann wrote:
From: Dietmar Eggemann dietmar.eggem...@arm.com
There is no need to zero struct sched_group member cpumask and struct
sched_group_power member power since both structures are already allocated
as zeroed memory in __sdt_alloc
[...]
(1) We assume that the current way (update_cpu_power() calls
arch_scale_freq_power() to get the avg power(freq) over the time period
since the last call to arch_scale_freq_power()) is suitable
for us. Do you have another opinion here?
Using power (or power_freq as you mentioned below)
From: Dietmar Eggemann dietmar.eggem...@arm.com
TOPOLOGY_SD_FLAGS contains all SD flags which provide topology related
information towards the scheduler. All other SD flags describe scheduler
behavioural aspects. The aim of TOPOLOGY_SD_FLAGS is to be able to check
that the arch only specifies
From: Dietmar Eggemann dietmar.eggem...@arm.com
Move cpu_smt_mask() and cpu_cpu_mask() from scheduler code into the
include/linux/topology.h so that an arch can use them for specifying cpu
masks for its topology info array.
Signed-off-by: Dietmar Eggemann dietmar.eggem...@arm.com
---
include
From: Dietmar Eggemann dietmar.eggem...@arm.com
Since all occurrences of SD_FOO_INIT have been deleted, there is no
need to export struct sched_domain any more.
Signed-off-by: Dietmar Eggemann dietmar.eggem...@arm.com
---
include/linux/sched.h | 87
kernel/sched
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch-set cleans up the scheduler domain (sd) level initialisation
code. It is based on the idea of Peter Zijlstra to use a single sd
init function sketched here: https://lkml.org/lkml/2013/11/5/239
The sd level data for conventional (SMT, MC
From: Dietmar Eggemann dietmar.eggem...@arm.com
The ARM arch_scale_freq_power function is the only one outside the core
scheduler code using struct sched_domain. This argument is not used in
the call chain. This patch deletes it to make it possible to un-export
struct sched_domain.
Signed-off
From: Dietmar Eggemann dietmar.eggem...@arm.com
The provision of the sd topology flag SD_ASYM_PACKING is shifted from the
weak function arch_sd_sibling_asym_packing() towards an arch specific
topology info table.
Signed-off-by: Dietmar Eggemann dietmar.eggem...@arm.com
---
arch/powerpc/kernel
From: Dietmar Eggemann dietmar.eggem...@arm.com
The idea behind creating the struct sched_domain_topology_info is to be
able to only export the scheduler data which can be changed by the arch.
Exporting the existing struct sched_domain_topology_level means that we
also have to expose struct
From: Dietmar Eggemann dietmar.eggem...@arm.com
Consolidate sched_init_numa() and sched_init_conv() into one function
sched_init_topology().
Signed-off-by: Dietmar Eggemann dietmar.eggem...@arm.com
---
kernel/sched/core.c | 164 +--
1 file
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch deletes all occurrences of SD_SIBLING_INIT, SD_MC_INIT,
SD_BOOK_INIT and SD_CPU_INIT.
The SD_NODE_INIT in arch/metag/include/asm/topology.h seems to be
leftover, probably because the metag arch got introduced at the same
time (v3.9
From: Dietmar Eggemann dietmar.eggem...@arm.com
To be able to set sd topology flags via the topology_info[] table
dependent on runtime information (cpu feature or per cpu), this patch
changes the provision of the sd topology flags from a simple int to a func
ptr.
The default flags func ptr
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch incorporates struct sched_domain_topology_info info into struct
sched_domain_topology_level. It updates sd_init_numa() to reflect the
change that conventional (SMT, MC, BOOK, CPU) level initialization relies
on the topology_info[] array
From: Dietmar Eggemann dietmar.eggem...@arm.com
With this patch, an arbitrary name for a sd level has to be specified in
the topology info table. This feature is still only active if
CONFIG_SCHED_DEBUG is set.
Signed-off-by: Dietmar Eggemann dietmar.eggem...@arm.com
---
include/linux/sched.h
On 20/12/13 14:04, Peter Zijlstra wrote:
+/*
+ * SD_flags allowed in topology descriptions.
+ *
+ * SD_SHARE_CPUPOWER - describes SMT topologies
+ * SD_SHARE_PKG_RESOURCES - describes shared caches
+ * SD_NUMA- describes NUMA topologies
+ *
+ * Odd one out:
+ *
On 20/12/13 14:08, Peter Zijlstra wrote:
On Fri, Dec 13, 2013 at 12:11:28PM +, dietmar.eggem...@arm.com wrote:
From: Dietmar Eggemann dietmar.eggem...@arm.com
In case the arch is allowed to define the conventional scheduler domain
topology level (i.e. the one without SD_NUMA topology flag
On 20/12/13 14:00, Peter Zijlstra wrote:
On Fri, Dec 13, 2013 at 12:11:20PM +, dietmar.eggem...@arm.com wrote:
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch-set cleans up the scheduler domain level initialization code.
It is based on the idea of Peter Zijlstra to use a single
On 07/01/14 10:22, Peter Zijlstra wrote:
On Mon, Jan 06, 2014 at 06:41:25PM +, Dietmar Eggemann wrote:
But the MC level cpu mask func ptr is called cpu_coregroup_mask.
Nothing a bit of sed won't cure very quickly indeed :-)
True, but that would mean that if two adjacent levels use
From: Dietmar Eggemann dietmar.eggem...@arm.com
Since is_same_group is only used in group scheduling code, there is
no need to define it outside CONFIG_FAIR_GROUP_SCHED.
Signed-off-by: Dietmar Eggemann dietmar.eggem...@arm.com
---
kernel/sched/fair.c |6 --
1 file changed, 6 deletions
On 31/01/14 14:04, Daniel Lezcano wrote:
On 01/31/2014 10:39 AM, Preeti U Murthy wrote:
Hi Peter,
On 01/31/2014 02:32 PM, Peter Zijlstra wrote:
On Fri, Jan 31, 2014 at 02:15:47PM +0530, Preeti Murthy wrote:
If the driver does its own random mapping that will break the governor
logic. So
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch provides the arch_sched_domain_info array for the ARM arch.
Signed-off-by: Dietmar Eggemann dietmar.eggem...@arm.com
---
arch/arm/kernel/topology.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/kernel
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch-set cleans up the scheduler domain level initialization code.
It is based on the idea of Peter Zijlstra to use a single scheduler domain
init function sketched here: https://lkml.org/lkml/2013/11/5/239
What does the patch-set try
From: Dietmar Eggemann dietmar.eggem...@arm.com
In case the arch is allowed to define the conventional scheduler domain
topology level (i.e. the one without SD_NUMA topology flag) layout, it is
not feasible any more for the scheduler to name these levels. Therefore,
this patch gets rid
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch replaces the call to the sched_domain_topology_level
initialization function pointer tl-init() with a call to sd_init() in
build_sched_domain(). It sets the cpu mask and the flags for each
conventional scheduler domain level (i.e
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch prepares the scheduler domain level set up code to be able to
not rely on the default_topology[] any more.
The NUMA specific function sched_init_numa, renamed to sched_alloc(), is
now for all systems to allocate the memory
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch prepares the scheduler domain level set up code to be able to
not rely on the default_topology[] any more.
The for_each_sd_topology macro is replaced with an explicit for loop
iterating over the sched_domain_topology array. It introduces
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch introduces the common scheduler domain level init function
sd_init and the definition of the topology related scheduler domain flags.
The sd_init function bases on the idea of Peter Zijlstra:
https://lkml.org/lkml/2013/11/5/239.
It should
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch defines an arch interface to provide the number of scheduler
domain levels, the pointer to the function returning the cpu mask and the
topology flags for each scheduler domain level.
The cpu mask getter functions for the smt and cpu level
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch provides the arch_sched_domain_info array for the x86 arch.
Signed-off-by: Dietmar Eggemann dietmar.eggem...@arm.com
---
arch/x86/kernel/topology.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kernel
On 21/03/14 11:04, Vincent Guittot wrote:
On 20 March 2014 18:18, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 20/03/14 17:02, Vincent Guittot wrote:
On 20 March 2014 13:41, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 19/03/14 16:22, Vincent Guittot wrote:
We replace the old
From: Dietmar Eggemann dietmar.eggem...@arm.com
There is no need to zero struct sched_group member cpumask and struct
sched_group_power member power since both structures are already allocated
as zeroed memory in __sdt_alloc().
This patch has been tested with
BUG_ON(!cpumask_empty
On 30/04/14 14:39, Dietmar Eggemann wrote:
From: Dietmar Eggemann dietmar.eggem...@arm.com
There is no need to zero struct sched_group member cpumask and struct
sched_group_power member power since both structures are already allocated
as zeroed memory in __sdt_alloc().
This patch has
On 24/04/14 08:30, Vincent Guittot wrote:
On 23 April 2014 17:26, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 23/04/14 15:46, Vincent Guittot wrote:
On 23 April 2014 13:46, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
Hi,
[...]
More than the flag that is used for the example
On 25/04/14 08:45, Vincent Guittot wrote:
[...]
Back than I had
CPU0: cpu_corepower_mask=0-1
CPU2: cpu_corepower_mask=2
so for GMC level the cpumasks are inconsistent across CPUs and it worked.
The example above is consistent because CPU2 mask and CPU0 mask are
fully exclusive
OK,
Hi,
I'm trying to use this approach of specifying different per-cpu views on
sd flags on DIE level on a TC2 platform (cluster 0 w/ CPU0/1 and cluster
1 w/ CPU2/3/4 w/o SMT). It doesn't work like in the case for the GMC/MC
sd level.
If I use the following patch (just to illustrate the issue) on
On 23/04/14 15:46, Vincent Guittot wrote:
On 23 April 2014 13:46, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
Hi,
I'm trying to use this approach of specifying different per-cpu views on
sd flags on DIE level on a TC2 platform (cluster 0 w/ CPU0/1 and cluster
1 w/ CPU2/3/4 w/o SMT
/2013/10/18/121
[2] https://lkml.org/lkml/2013/11/5/239
[3] https://lkml.org/lkml/2013/11/5/449
Hi Vincent,
given the discussion we had for v1-v3 and a short boot test of v4:
For patch 1/5, 4/5, 5/5 on ARM TC2 (heterogeneous dual socket w/o SMT
machine):
Reviewed-by: Dietmar Eggemann
.
+ }
+
}
set_domain_attribute(sd, attr);
Tested-by: Dietmar Eggemann dietmar.eggem...@arm.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 23/07/14 10:31, Michel Dänzer wrote:
On 23.07.2014 18:25, Peter Zijlstra wrote:
On Wed, Jul 23, 2014 at 10:28:19AM +0200, Peter Zijlstra wrote:
Of course, the other thing that patch did is clear sgp-power (now
sgc-capacity).
Hmm, re-reading the thread there isn't a clear confirmation
[...]
In that same discussion ISTR a suggestion about adding avg_running time,
as opposed to the current avg_runnable. The sum of avg_running should be
much more accurate, and still react correctly to migrations.
I haven't look in details but I agree that avg_running would be much
more
Hi Vincent,
On 18/12/13 14:13, Vincent Guittot wrote:
This patch applies on top of the two patches [1][2] that have been proposed by
Peter for creating a new way to initialize sched_domain. It includes some minor
compilation fixes and a trial of using this new method on ARM platform.
[1]
Hi Bruno and Josh,
On 16/07/14 17:17, Josh Boyer wrote:
Adding Dietmar in since he is the original author.
josh
On Wed, Jul 16, 2014 at 09:55:46AM -0500, Bruno Wolff III wrote:
caffcdd8d27ba78730d5540396ce72ad022aff2c has been causing crashes
early in the boot process on one of three
Hi Greg,
On 16/07/14 19:52, Greg Donald wrote:
On Wed, Jul 16, 2014 at 05:27:36PM +0200, Peter Zijlstra wrote:
Could you confirm if reverting caffcdd8d27ba78730d5540396ce72ad022aff2c
cures things for you?
Otherwise there's two very similar issues, see also:
On 16/07/14 21:54, Bruno Wolff III wrote:
On Wed, Jul 16, 2014 at 21:17:32 +0200,
Dietmar Eggemann dietmar.eggem...@arm.com wrote:
Hi Bruno and Josh,
From the issue, I see that the machine making trouble is an Xeon (2
processors w/ hyper-threading).
Could you please share:
cat /proc
On 17/07/14 05:09, Bruno Wolff III wrote:
On Thu, Jul 17, 2014 at 01:18:36 +0200,
Dietmar Eggemann dietmar.eggem...@arm.com wrote:
So the output of
$ cat /proc/sys/kernel/sched_domain/cpu*/domain*/*
would be handy too.
Thanks, this was helpful.
I see from the sched domain layout that you
On 17/07/14 11:04, Peter Zijlstra wrote:
On Thu, Jul 17, 2014 at 10:57:55AM +0200, Dietmar Eggemann wrote:
There is also the possibility that the memory for sched_group sg is not
(completely) zeroed out:
sg = kzalloc_node(sizeof(struct sched_group) + cpumask_size
On 17/07/14 18:36, Bruno Wolff III wrote:
I did a few quick boots this morning while taking a bunch of pictures. I have
gone through some of them this morning and found one that shows bug on
was triggered at 5850 which is from:
BUG_ON(!cpumask_empty(sched_group_cpus(sg)));
You can see the JPEG
On 18/07/14 07:34, Bruno Wolff III wrote:
On Thu, Jul 17, 2014 at 14:35:02 +0200,
Peter Zijlstra pet...@infradead.org wrote:
In any case, can someone who can trigger this run with the below; its
'clean' for me, but supposedly you'll trigger a FAIL somewhere.
I got a couple of fail
On 18/07/14 15:01, Bruno Wolff III wrote:
On Fri, Jul 18, 2014 at 12:16:33 +0200,
Peter Zijlstra pet...@infradead.org wrote:
So it looks like the actual domain tree is broken, and not what we
assumed it was.
Could I bother you to run with the below instead? It should also print
out the
Hi Sukadev,
On 30/07/14 08:22, Sukadev Bhattiprolu wrote:
I am getting this crash on a Powerpc system using 3.16.0-rc7 kernel plus
some patches related to perf (24x7 counters) that Cody Schafer posted here:
https://lkml.org/lkml/2014/5/27/768
I don't get the crash on an unpatched
On 04/08/14 04:20, Michael Ellerman wrote:
On Fri, 2014-08-01 at 14:24 -0700, Sukadev Bhattiprolu wrote:
Dietmar Eggemann [dietmar.eggem...@arm.com] wrote:
| ltcbrazos2-lp07 login: [ 181.915974] [ cut here
]
| [ 181.915991] WARNING: at ../kernel/sched/core.c:5881
On 10/10/14 04:21, Yuyang Du wrote:
[...]
@@ -331,21 +330,16 @@ struct cfs_rq {
#ifdef CONFIG_SMP
/*
-* CFS Load tracking
-* Under CFS, load is tracked on a per-entity basis and aggregated up.
-* This allows for the description of both thread and group usage
On 10/10/14 04:21, Yuyang Du wrote:
[...]
@@ -331,21 +330,16 @@ struct cfs_rq {
#ifdef CONFIG_SMP
/*
-* CFS Load tracking
-* Under CFS, load is tracked on a per-entity basis and aggregated up.
-* This allows for the description of both thread and group usage
Hi Yuyang,
On 08/10/14 01:50, Yuyang Du wrote:
Hi Morten,
Sorry for late jumping in.
The problem seems to be self-evident. But for the implementation to be
equally attractive it needs to account for every freq change for every task,
or anything less than that makes it less attractive.
On 07/10/14 13:13, Vincent Guittot wrote:
Add new statistics which reflect the average time a task is running on the CPU
and the sum of these running time of the tasks on a runqueue. The latter is
named utilization_avg_contrib.
This patch is based on the usage metric that was proposed in the
Hi,
On 30/09/14 13:34, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/30/2014 07:56 AM, Arnd Bergmann wrote:
A recent change to update the stime/utime members of task_struct
using atomic cmpxchg broke configurations on 32-bit machines with
Hi Mike,
On 22/10/14 07:07, Mike Turquette wrote:
{en,de}queue_task_fair are updated to track which cpus will have changed
utilization values as function of task queueing.
The sentence is a little bit misleading. We update the se utilization
contrib and the cfs_rq utilization in
On 22/10/14 07:07, Mike Turquette wrote:
Building on top of the scale invariant capacity patches and earlier
We don't have scale invariant capacity yet but scale invariant
load/utilization.
patches in this series that prepare CFS for scaling cpu frequency, this
patch implements a simple,
On 14/09/14 12:41, Peter Zijlstra wrote:
On Thu, Sep 11, 2014 at 07:26:48PM +0200, Vincent Guittot wrote:
On 11 September 2014 18:15, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Aug 26, 2014 at 01:06:54PM +0200, Vincent Guittot wrote:
+static inline int group_has_free_capacity(struct
On 26/09/14 13:39, Vincent Guittot wrote:
On 25 September 2014 21:19, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 25/09/14 09:35, Vincent Guittot wrote:
[snip]
In case sgs-group_type is group_overloaded you could set
sgs-group_out_of_capacity to 1 without calling
On 26/09/14 13:17, Vincent Guittot wrote:
On 25 September 2014 21:05, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 23/09/14 17:08, Vincent Guittot wrote:
[...]
+static int get_cpu_usage(int cpu)
+{
+ unsigned long usage = cpu_rq(cpu)-cfs.utilization_load_avg;
+ unsigned
On 23/09/14 17:08, Vincent Guittot wrote:
The scheduler tries to compute how many tasks a group of CPUs can handle by
assuming that a task's load is SCHED_LOAD_SCALE and a CPU capacity is
SCHED_CAPACITY_SCALE but the capacity_factor is hardly working for SMT system,
it sometimes works for big
On 23/09/14 17:08, Vincent Guittot wrote:
[...]
Finally, the sched_group-sched_group_capacity-capacity_orig has been removed
because it's more used during load balance.
So you're not forced to call it rq-cpu_capacity_orig any more, you
could use rq-cpu_capacity_max instead.
[...]
This
On 23/09/14 17:08, Vincent Guittot wrote:
Monitor the usage level of each group of each sched_domain level. The usage is
the amount of cpu_capacity that is currently used on a CPU or group of CPUs.
We use the utilization_load_avg to evaluate the usage level of each group.
Signed-off-by:
On 25/09/14 09:35, Vincent Guittot wrote:
On 24 September 2014 19:48, Dietmar Eggemann dietmar.eggem...@arm.com wrote:
On 23/09/14 17:08, Vincent Guittot wrote:
[snip]
This review (by PeterZ) during v5 of your patch-set recommended some
renaming (e.g. s/group_has_free_capacity
On 21/11/14 12:35, Morten Rasmussen wrote:
On Mon, Nov 03, 2014 at 04:54:41PM +, Vincent Guittot wrote:
From: Morten Rasmussen morten.rasmus...@arm.com
Could we rename this patch to 'sched: Make usage tracking frequency
scale-invariant'?
The reason is, since we scale
.
-- Dietmar
https://git.linaro.org/people/mturquette/linux.git eas-next
commit 1fadb581b0be9420b143e43ff2f4a07ea7e45f6c
Author: Dietmar Eggemann dietmar.eggem...@arm.com
AuthorDate: Tue Dec 2 14:06:24 2014 +
Commit: Michael Turquette mturque...@deferred.io
CommitDate: Tue Dec 9 20:33
On 24/03/15 13:41, Peter Zijlstra wrote:
On Wed, Feb 04, 2015 at 06:31:15PM +, Morten Rasmussen wrote:
+ .use_ea = (energy_aware() sd-groups-sge) ? true :
false,
The return value of a logical and should already be a boolean.
Indeed, thanks for spotting this!
On 24/03/15 13:56, Peter Zijlstra wrote:
On Wed, Feb 04, 2015 at 06:31:15PM +, Morten Rasmussen wrote:
From: Dietmar Eggemann dietmar.eggem...@arm.com
Energy-aware load balancing should only happen if the ENERGY_AWARE feature
is turned on and the sched domain on which the load balancing
1 - 100 of 1404 matches
Mail list logo
