On 15/04/2021 20:09, Valentin Schneider wrote:
> On 14/04/21 20:23, Ruifeng Zhang wrote:
>> From: Ruifeng Zhang
>>
>> In Unisoc, the sc9863a SoC which using cortex-a55, it has two software
>> version, one of them is the kernel running on EL1 using aarch32.
>> user(EL0)
On 16/04/2021 11:32, Valentin Schneider wrote:
> On 16/04/21 15:47, Ruifeng Zhang wrote:
>> For more requirements, if all cores in one physical cluster, the
>> {aff2} of all cores are the same value.
>> i.e. the sc9863a,
>> core0: 8100
>> core1: 81000100
>> core2: 810002
On 16/04/2021 13:04, Ruifeng Zhang wrote:
> Dietmar Eggemann 于2021年4月16日周五 下午6:39写道：
>>
>> On 16/04/2021 11:32, Valentin Schneider wrote:
>>> On 16/04/21 15:47, Ruifeng Zhang wrote:
[...]
>> I'm confused. Do you have the MT bit set to 1 then? So the issue th
On 12/04/2021 14:20, Ruifeng Zhang wrote:
> Valentin Schneider 于2021年4月12日周一 下午7:32写道：
>>
>>
>> Hi,
>>
>> On 12/04/21 15:08, Ruifeng Zhang wrote:
>>> From: Ruifeng Zhang
>>>
>>> The arm topology still parse from the MPIDR, but it is incomplete. When
>>> the armv8.3 cpu runs in aarch32 mode, it w
unsigned intnr_numa_running;
I forgot to remove this snippet back then. LGTM.
Add a
Fixes: 55627e3cd22c ("sched/core: Remove rq->cpu_load[]")
line.
Reviewed-by: Dietmar Eggemann
On 13/04/2021 18:28, Steven Rostedt wrote:
> On Tue, 13 Apr 2021 10:36:07 +0200
> Dietmar Eggemann wrote:
[...]
>> Add a
>>
>> Fixes: 55627e3cd22c ("sched/core: Remove rq->cpu_load[]")
>>
>> line.
>
> It's just removing a comment.
On 13/04/2021 15:26, Ruifeng Zhang wrote:
> Thanks for your review. Patch-v2 that solve the capacity issue will be
> uploaded as soon as possible. : )
>
> Valentin Schneider 于2021年4月13日周二 下午7:40写道：
>>
>> On 13/04/21 14:13, Ruifeng Zhang wrote:
>>> Valentin Schneider 于2021年4月12日周一 下午11:33写道：
On 14/04/2021 13:26, Ruifeng Zhang wrote:
> Dietmar Eggemann 于2021年4月14日周三 下午5:43写道：
>>
>> On 13/04/2021 15:26, Ruifeng Zhang wrote:
>>> Thanks for your review. Patch-v2 that solve the capacity issue will be
>>> uploaded as soon as possible. : )
>>>
>
;
> - BUG_ON(newpri >= CPUPRI_NR_PRIORITIES);
> -
> if (newpri == oldpri)
> return;
>
>
LGTM. Currently, convert_prio() is never called with prio <
CPUPRI_INVALID (-1) or prio > MAX_RT_PRIO (100) but in case it would
then this would be caught much easier with this patch.
Reviewed-by: Dietmar Eggemann
On 01/04/2021 21:30, Valentin Schneider wrote:
> From: Lingutla Chandrasekhar
>
> During load balance, LBF_SOME_PINNED will bet set if any candidate task
nitpick; s/bet/be ?
[...]
Reviewed-by: Dietmar Eggemann
r even happens on the CPU that appended the stopper work.
>
> Add a struct lb_env flag to denote active balancing, and use it in
> can_migrate_task(). Remove the sd->nr_balance_failed write that served the
> same purpose. Cleanup the LBF_DST_PINNED active balance special case.
>
> Signed-off-by: Valentin Schneider
Reviewed-by: Dietmar Eggemann
[...]
t CPU makes really sense
here. Might be worth mentioning in the patch header why. There is some
of it in v3 6/7 but that's a different change.
Reviewed-by: Dietmar Eggemann
[...]
+cc: Pierre Gondois
On 30/03/2021 11:45, Quentin Perret wrote:
> Hi,
>
> On Tuesday 30 Mar 2021 at 13:21:54 (+0800), Xuewen Yan wrote:
>> From: Xuewen Yan
>>
>> now the energy delta compute as follow:
>>
>> base_energy_pd = compute_energy(p, -1, pd);
>> --->Traverse all CPUs in pd
>>
On 19/04/2021 04:55, Ruifeng Zhang wrote:
> Dietmar Eggemann 于2021年4月17日周六 上午1:00写道：
>>
>> On 16/04/2021 13:04, Ruifeng Zhang wrote:
>>> Dietmar Eggemann 于2021年4月16日周五 下午6:39写道：
>>>>
>>>> On 16/04/2021 11:32, Valentin Schneider wrote:
>>>
On 11/03/2021 13:05, Valentin Schneider wrote:
[...]
> @@ -9952,7 +9954,8 @@ static int active_load_balance_cpu_stop(void *data)
>* @dst_grpmask we need to make that test go away with
> lying
>* about DST_PINNED.
>*/
> -
On 24/11/2020 14:22, Viresh Kumar wrote:
> On 24-11-20, 09:10, Quentin Perret wrote:
>> Hey Viresh,
>>
>> On Tuesday 24 Nov 2020 at 11:56:15 (+0530), Viresh Kumar wrote:
>>> There is nothing schedutil specific in schedutil_cpu_util(), rename it
>>> to effective_cpu_util(). Also create and expose an
On 01/12/2020 03:59, Barry Song wrote:
[...]
> Although I believe there is still a lot to do, sending a RFC to get feedbacks
> of community experts might be helpful for the next step.
>
> Barry Song (1):
> scheduler: add scheduler level for clusters
>
> Jonathan Cameron (1):
> topology: Rep
On 23/11/2020 14:42, Vincent Guittot wrote:
> On Mon, 23 Nov 2020 at 12:27, Dietmar Eggemann
> wrote:
>>
>> On 23/11/2020 11:05, Vincent Guittot wrote:
>>> On Mon, 23 Nov 2020 at 10:30, Dietmar Eggemann
>>> wrote:
>>>>
>>>> On 20/11/
der to predict the performance state, map the utilization of
>* the most utilized CPU of the performance domain to a requested
LGTM.
Reviewed-by: Dietmar Eggemann
util_est_dequeue()
(B) task_util_est update in util_est_update()
Place (A) before (1) and keep (B) where (2) is. The latter is necessary
since (B) relies on task_util update in (1).
---
What do you think?
>
> Signed-off-by: Xuewen Yan
> Signed-off-by: Dietmar Eggemann
Please remo
On 24/11/2020 07:26, Viresh Kumar wrote:
> Several parts of the kernel are already using the effective CPU
> utilization (as seen by the scheduler) to get the current load on the
> CPU, do the same here instead of depending on the idle time of the CPU,
> which isn't that accurate comparatively.
>
On 26/02/2021 09:41, Peter Zijlstra wrote:
> On Thu, Feb 25, 2021 at 04:58:20PM +, Vincent Donnefort wrote:
>> +#define UTIL_EST_MARGIN (SCHED_CAPACITY_SCALE / 100)
>> +
>> /*
>> - * Check if a (signed) value is within a specified (unsigned) margin,
>> + * Check if a (signed) value is within t
On 26/02/2021 17:40, Srikar Dronamraju wrote:
[...]
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8a8bd7b13634..d49bfcdc4a19 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5869,6 +5869,36 @@ wake_affine_weight(struct sched_domain *sd, struct
> task_struct
Hi Michal,
On 25/02/2021 17:27, Michal Koutný wrote:
> leaf_cfs_rq_list should contain cfs_rqs that have runnable entities in
> them. When we're operating under a throttled hierarchy we always update
> the leaf_cfs_rq_list in order no to break list_add_leaf_cfs_rq invariant
> of adding complete b
On 21/01/2021 19:21, Valentin Schneider wrote:
> On 21/01/21 19:39, Meelis Roos wrote:
>>> Could you paste the output of the below?
>>>
>>>$ cat /sys/devices/system/node/node*/distance
>>
>> 10 12 12 14 14 14 14 16
>> 12 10 14 12 14 14 12 14
>> 12 14 10 14 12 12 14 14
>> 14 12 14 10 12 12 14 14
On 21/01/2021 22:17, Song Bao Hua (Barry Song) wrote:
>
>
>> -Original Message-----
>> From: Dietmar Eggemann [mailto:dietmar.eggem...@arm.com]
>> Sent: Friday, January 22, 2021 7:54 AM
>> To: Valentin Schneider ; Meelis Roos
>> ; LKML
>> Cc: Pete
On 25/01/2021 11:50, Song Bao Hua (Barry Song) wrote:
>
>> -Original Message-
>> From: Dietmar Eggemann [mailto:dietmar.eggem...@arm.com]
>> Sent: Wednesday, January 13, 2021 12:00 AM
>> To: Morten Rasmussen ; Tim Chen
>>
>> Cc: Song Bao Hua (Barr
On 12/01/2021 16:53, Daniel Bristot de Oliveira wrote:
[...]
> - %< -
> #!/bin/bash
> # Enter on the cgroup directory
> cd /sys/fs/cgroup/
>
> # Check it if is cgroup v2 and enable cpuset
> if [ -e cgroup.subtree_control ]; then
> # Enable cpuset controller on cgroup v2
>
On 22/01/2021 20:10, Joel Fernandes wrote:
> Hi Vincent,
>
> Thanks for reply. Please see the replies below:
>
> On Fri, Jan 22, 2021 at 05:56:22PM +0100, Vincent Guittot wrote:
>> On Fri, 22 Jan 2021 at 16:46, Joel Fernandes (Google)
>> wrote:
>>>
>>> On an octacore ARM64 device running ChromeO
On 25/01/2021 18:30, Vincent Guittot wrote:
> On Mon, 25 Jan 2021 at 11:45, Dietmar Eggemann
> wrote:
>>
>> On 22/01/2021 20:10, Joel Fernandes wrote:
>>> Hi Vincent,
>>>
>>> Thanks for reply. Please see the replies below:
>>>
>>>
t why this range is mentioned here? Maybe
the influence of the 'sleep-bonus interactivity' feature which was
removed by commit f3479f10c5d6 ("sched: remove the sleep-bonus
interactivity code")?
Dietmar Eggemann (3):
sched: Remove MAX_USER_RT_PRIO
sched: Remove
Get rid of MAX_USER_RT_PRIO and make everything use MAX_RT_PRIO
instead.
Signed-off-by: Dietmar Eggemann
---
include/linux/sched/prio.h | 9 +
kernel/sched/core.c| 7 +++
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/include/linux/sched/prio.h b/include/linux/sched/pr
The description of the RT offset and the values for 'normal' tasks needs
update. Moreover there are DL tasks now.
task_prio() has to stay like it is to guarantee compatibility with the
/proc//stat priority field:
# cat /proc//stat | awk '{ print $18; }'
Signed-off-
he
{*_}USER_PRIO defines.
Signed-off-by: Dietmar Eggemann
---
arch/powerpc/platforms/cell/spufs/sched.c | 2 +-
include/linux/sched/prio.h| 9 -
kernel/sched/sched.h | 2 +-
3 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/powe
On 15/12/2020 13:56, Xuewen Yan wrote:
> On Tue, Dec 15, 2020 at 5:39 PM Vincent Guittot
> wrote:
>>
>> On Mon, 14 Dec 2020 at 19:46, Dietmar Eggemann
>> wrote:
>>>
>>> On 11/12/2020 13:03, Ryan Y wrote:
[...]
>>> It's true
On 09/12/2020 11:44, Xuewen Yan wrote:
> when a task dequeued, it will update it's util, and cfs_rq_util_change
> would check rq's util, if the cfs_rq->avg.util_est.enqueued is bigger
> than cfs_rq->avg.util_avg, but because the cfs_rq->avg.util_est.enqueued
> didn't be decreased, this would cause
ping) task.
If I would run with your patch cpu_util_cfs() would chose between 597 and 0
whereas without it does between 597 and 601.
Do you have a specific use case in mind? Or even test results showing a benefit
of your patch?
> Dietmar Eggemann 于2020年12月11日周五 下午7:30写道：
>
>> Hi Yan,
&
On 20/11/2020 08:55, Peter Zijlstra wrote:
[...]
> PELT (Per Entity Load Tracking)
> ---
[...]
> Using this we track 2 key metrics: 'running' and 'runnable'. 'Running'
> reflects the time an entity spends on the CPU, while 'runnable' reflects the
> time an entity spe
On 20/11/2020 09:56, Peter Zijlstra wrote:
> On Fri, Nov 20, 2020 at 08:55:27AM +0100, Peter Zijlstra wrote:
>> - In saturated scenarios task movement will cause some transient dips,
>>suppose we have a CPU saturated with 4 tasks, then when we migrate a task
>>to an idle CPU, the old CPU w
On 23/11/2020 11:05, Vincent Guittot wrote:
> On Mon, 23 Nov 2020 at 10:30, Dietmar Eggemann
> wrote:
>>
>> On 20/11/2020 09:56, Peter Zijlstra wrote:
>>> On Fri, Nov 20, 2020 at 08:55:27AM +0100, Peter Zijlstra wrote:
>>>> - In saturated scenarios task
From: Dietmar Eggemann
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 !CONFIG_FAIR_GROUP_SCHED case
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 !CON
On 25/02/14 20:52, Peter Zijlstra wrote:
> On Tue, Feb 25, 2014 at 11:47:42AM +0000, Dietmar Eggemann wrote:
>> +++ b/kernel/sched/sched.h
>> @@ -630,7 +630,9 @@ struct rq {
>> struct llist_head wake_list;
>> #endif
>>
>> +#ifdef CONFIG_FAIR_G
On 12/03/14 07:44, Vincent Guittot wrote:
> On 12 March 2014 05:42, Preeti U Murthy wrote:
>> On 03/11/2014 06:48 PM, Vincent Guittot wrote:
>>> On 11 March 2014 11:08, Preeti U Murthy wrote:
Hi Vincent,
On 03/05/2014 12:48 PM, Vincent Guittot wrote:
> Create a dedicated topolo
On 11/03/14 13:17, Peter Zijlstra wrote:
> On Sat, Mar 08, 2014 at 12:40:58PM +0000, 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
>&
On 12/03/14 13:47, Vincent Guittot wrote:
> On 12 March 2014 14:28, Dietmar Eggemann 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
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 than
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 cpu_p
On 06/03/14 09:04, Vincent Guittot wrote:
On 6 March 2014 07:17, Dietmar Eggemann 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) to make the
thing
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 le
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,
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-
On 17/03/14 11:52, Peter Zijlstra wrote:
> On Wed, Mar 12, 2014 at 01:28:07PM +0000, 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
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 le
On 20/03/14 17:02, Vincent Guittot wrote:
> On 20 March 2014 13:41, Dietmar Eggemann 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 a
On 07/01/14 10:22, Peter Zijlstra wrote:
> On Mon, Jan 06, 2014 at 06:41:25PM +0000, 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
tune sched_domain
in each individual level.
Below is a patch which bases on your idea to transform sd_numa_init()
into sd_init(). The main difference is that I don't try to distinguish
based of power management related flags inside sd_init() but rather on
the new sd level data.
Dietmar
8&
From: Dietmar Eggemann
This patch provides the arch_sched_domain_info array for the ARM arch.
Signed-off-by: Dietmar Eggemann
---
arch/arm/kernel/topology.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index
From: Dietmar Eggemann
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 to achieve:
1) Let the arch
From: Dietmar Eggemann
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 of of the
From: Dietmar Eggemann
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. the one without SD_N
From: Dietmar Eggemann
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 for the
sched_domain_topology_level
From: Dietmar Eggemann
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 the file
global
From: Dietmar Eggemann
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 replace all default
From: Dietmar Eggemann
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 as well as the
function
From: Dietmar Eggemann
This patch provides the arch_sched_domain_info array for the x86 arch.
Signed-off-by: Dietmar Eggemann
---
arch/x86/kernel/topology.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/topology.c
index
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 a
On 18/07/14 07:34, Bruno Wolff III wrote:
On Thu, Jul 17, 2014 at 14:35:02 +0200,
Peter Zijlstra 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 messages.
dmesg output is a
On 18/07/14 15:01, Bruno Wolff III wrote:
On Fri, Jul 18, 2014 at 12:16:33 +0200,
Peter Zijlstra 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 sched domain masks so we
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 to
On 23/04/14 15:46, Vincent Guittot wrote:
> On 23 April 2014 13:46, Dietmar Eggemann 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
On 24/04/14 08:30, Vincent Guittot wrote:
> On 23 April 2014 17:26, Dietmar Eggemann wrote:
>> On 23/04/14 15:46, Vincent Guittot wrote:
>>> On 23 April 2014 13:46, Dietmar Eggemann wrote:
>>>> Hi,
[...]
>
> More than the flag that is used for the example
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 unpa
From: Dietmar Eggemann
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 topology related flags in
From: Dietmar Eggemann
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
---
include/linux/topology.h | 12
kernel/sched
From: Dietmar Eggemann
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
---
include/linux/sched.h | 87
kernel/sched/sched.h | 153
From: Dietmar Eggemann
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, BOOK, CPU) sd levels
From: Dietmar Eggemann
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-by: Dietmar Eggemann
From: Dietmar Eggemann
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
---
arch/powerpc/kernel/smp.c | 34
From: Dietmar Eggemann
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 sd_data anf other scheduler
From: Dietmar Eggemann
Consolidate sched_init_numa() and sched_init_conv() into one function
sched_init_topology().
Signed-off-by: Dietmar Eggemann
---
kernel/sched/core.c | 164 +--
1 file changed, 68 insertions(+), 96 deletions(-)
diff --git
From: Dietmar Eggemann
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) the other archs moved away
From: Dietmar Eggemann
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 for SMT and MC level are
From: Dietmar Eggemann
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 and not on the
From: Dietmar Eggemann
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
---
include/linux/sched.h | 11 ++-
kernel/sched/core.c | 23
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.
[...]
Th
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 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/
On 26/09/14 13:39, Vincent Guittot wrote:
> On 25 September 2014 21:19, Dietmar Eggemann wrote:
>> On 25/09/14 09:35, Vincent Guittot wrote:
>
> [snip]
>
>>>>
>>>> In case sgs->group_type is group_overloaded you could set
>>>> sgs->gr
On 26/09/14 13:17, Vincent Guittot wrote:
> On 25 September 2014 21:05, Dietmar Eggemann wrote:
>> On 23/09/14 17:08, Vincent Guittot wrote:
[...]
>>>
>>> +static int get_cpu_usage(int cpu)
>>> +{
>>> + unsigned long usage = cpu_rq(cpu)->c
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 b
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
>> CONFIG_VIRT_C
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 wrote:
On Tue, Aug 26, 2014 at 01:06:54PM +0200, Vincent Guittot wrote:
+static inline int group_has_free_capacity(struct sg_lb_stats *sgs,
+
On 07/03/14 02:47, Vincent Guittot wrote:
On 6 March 2014 20:31, Dietmar Eggemann wrote:
On 06/03/14 09:04, Vincent Guittot wrote:
On 6 March 2014 07:17, Dietmar Eggemann wrote:
On 05/03/14 07:18, Vincent Guittot wrote:
This patchset was previously part of the larger tasks packing
On 11/03/14 13:27, Vincent Guittot wrote:
> On 11 March 2014 11:31, Peter Zijlstra 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 or
sc
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 exc
From: Dietmar Eggemann
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(sched_group_cpus(sg))); and BUG_ON(sg
On 30/04/14 14:39, Dietmar Eggemann wrote:
> From: Dietmar Eggemann
>
> 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
Hi Peter,
On 30/04/14 14:39, Dietmar Eggemann wrote:
> From: Dietmar Eggemann
>
> 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().
>
>
201 - 300 of 871 matches
Mail list logo
