From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Vincent Guittot <vincent.guittot@linaro.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"mingo@kernel.org" <mingo@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"tony.luck@intel.com" <tony.luck@intel.com>,
"fenghua.yu@intel.com" <fenghua.yu@intel.com>,
"schwidefsky@de.ibm.com" <schwidefsky@de.ibm.com>,
"james.hogan@imgtec.com" <james.hogan@imgtec.com>,
"cmetcalf@tilera.com" <cmetcalf@tilera.com>,
"benh@kernel.crashing.org" <benh@kernel.crashing.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Cc: "preeti@linux.vnet.ibm.com" <preeti@linux.vnet.ibm.com>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>
Subject: Re: [RFC 0/6] rework sched_domain topology description
Date: Wed, 05 Mar 2014 23:17:38 +0000 [thread overview]
Message-ID: <5317B092.7070805@arm.com> (raw)
In-Reply-To: <1394003906-11630-1-git-send-email-vincent.guittot@linaro.org>
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_power
> -tasks packing algorithm
>
> Based on Peter Z's proposal [2][3], this patchset modifies the way to configure
> the sched_domain level in order to let architectures to add specific level like
> the current BOOK level or the proposed power gating level for ARM architecture.
>
> [1] https://lkml.org/lkml/2013/10/18/121
> [2] https://lkml.org/lkml/2013/11/5/239
> [3] https://lkml.org/lkml/2013/11/5/449
>
> Vincent Guittot (6):
> sched: remove unused SCHED_INIT_NODE
> sched: rework of sched_domain topology definition
> sched: s390: create a dedicated topology table
> sched: powerpc: create a dedicated topology table
> sched: add a new SD_SHARE_POWERDOMAIN for sched_domain
> sched: ARM: create a dedicated scheduler topology table
>
> arch/arm/kernel/topology.c | 26 ++++
> arch/ia64/include/asm/topology.h | 24 ----
> arch/metag/include/asm/topology.h | 27 -----
> arch/powerpc/kernel/smp.c | 35 ++++--
> arch/s390/include/asm/topology.h | 13 +-
> arch/s390/kernel/topology.c | 25 ++++
> arch/tile/include/asm/topology.h | 33 ------
> include/linux/sched.h | 30 +++++
> include/linux/topology.h | 128 ++------------------
> kernel/sched/core.c | 235 ++++++++++++++++++-------------------
> 10 files changed, 237 insertions(+), 339 deletions(-)
>
Hi Vincent,
I reviewed your patch-set carefully (including test runs on TC2),
especially due to the fact that we want to build our sd_energy stuff on
top of it.
One thing I'm still not convinced of is the fact that specifying
additional sd levels in the struct sched_domain_topology_level table has
an advantage over a function pointer for sd topology flags similar to
the one we're already using for the cpu mask in struct
sched_domain_topology_level.
int (*sched_domain_flags_f)(int cpu);
This function pointer would be simply another member of struct
sched_domain_topology_level and would replace int sd_flags. AFAICS, you
have to create additional cpu mask functions anyway for the additional
sd levels, like cpu_corepower_mask() for the GMC level in the ARM case.
There could be a set of standard sd topology flags function for the
default sd layer and archs which want to pass in something special
define those function locally since they will use them only in their
arch specific struct sched_domain_topology_level table anyway. I know
that you use the existing sd degenerate functionality for this and that
the freeing of the redundant data structures (sched_domain, sched_group
and sched_group_power) is there too but it still doesn't seem to me to
be the right thing to do.
The problem that we now expose internal data structures (struct sd_data
and struct sched_domain_topology_level) could be dealt with later.
-- Dietmar
next prev parent reply other threads:[~2014-03-05 23:17 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 7:18 [RFC 0/6] rework sched_domain topology description Vincent Guittot
2014-03-05 7:18 ` [RFC 1/6] sched: remove unused SCHED_INIT_NODE Vincent Guittot
2014-03-05 7:18 ` [PATCH 2/6] sched: rework of sched_domain topology definition Vincent Guittot
2014-03-05 17:09 ` Dietmar Eggemann
2014-03-06 8:32 ` Vincent Guittot
2014-03-11 10:31 ` Peter Zijlstra
2014-03-11 13:27 ` Vincent Guittot
2014-03-11 13:48 ` Dietmar Eggemann
2014-03-05 7:18 ` [RFC 3/6] sched: s390: create a dedicated topology table Vincent Guittot
2014-03-05 7:18 ` [RFC 4/6] sched: powerpc: " Vincent Guittot
2014-03-11 10:08 ` Preeti U Murthy
2014-03-11 13:18 ` Vincent Guittot
2014-03-12 4:42 ` Preeti U Murthy
2014-03-12 7:44 ` Vincent Guittot
2014-03-12 11:04 ` Dietmar Eggemann
2014-03-14 2:30 ` Preeti U Murthy
2014-03-14 2:14 ` Preeti U Murthy
2014-03-05 7:18 ` [RFC 5/6] sched: add a new SD_SHARE_POWERDOMAIN for sched_domain Vincent Guittot
2014-03-05 7:18 ` [RFC 6/6] sched: ARM: create a dedicated scheduler topology table Vincent Guittot
2014-03-05 22:38 ` Dietmar Eggemann
2014-03-06 8:42 ` Vincent Guittot
2014-03-05 23:17 ` Dietmar Eggemann [this message]
2014-03-06 9:04 ` [RFC 0/6] rework sched_domain topology description Vincent Guittot
2014-03-06 12:31 ` Dietmar Eggemann
2014-03-07 2:47 ` Vincent Guittot
2014-03-08 12:40 ` Dietmar Eggemann
2014-03-10 13:21 ` Vincent Guittot
2014-03-11 13:17 ` Peter Zijlstra
2014-03-12 13:28 ` Dietmar Eggemann
2014-03-12 13:47 ` Vincent Guittot
2014-03-13 14:07 ` Dietmar Eggemann
2014-03-17 11:52 ` Peter Zijlstra
2014-03-19 19:15 ` Dietmar Eggemann
2014-03-20 8:28 ` Vincent Guittot
2014-03-11 13:08 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5317B092.7070805@arm.com \
--to=dietmar.eggemann@arm.com \
--cc=benh@kernel.crashing.org \
--cc=cmetcalf@tilera.com \
--cc=fenghua.yu@intel.com \
--cc=james.hogan@imgtec.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=preeti@linux.vnet.ibm.com \
--cc=schwidefsky@de.ibm.com \
--cc=tony.luck@intel.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).