From: Namhyung Kim <namhyung@kernel.org>
To: Michael Wang <wangyun@linux.vnet.ibm.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Turner <pjt@google.com>, Tejun Heo <tj@kernel.org>,
Mike Galbraith <efault@gmx.de>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 1/2] sched: schedule balance map foundation
Date: Mon, 14 Jan 2013 17:26:40 +0900 [thread overview]
Message-ID: <87libwnpa7.fsf@sejong.aot.lge.com> (raw)
In-Reply-To: <50EFCAA7.8080302@linux.vnet.ibm.com> (Michael Wang's message of "Fri, 11 Jan 2013 16:17:43 +0800")
Hi Michael,
On Fri, 11 Jan 2013 16:17:43 +0800, Michael Wang wrote:
> In order to get rid of the complex code in select_task_rq_fair(),
> approach to directly get sd on each level with proper flag is
> required.
>
> Schedule balance map is the solution, which record the sd according
> to it's flag and level.
>
> For example, cpu_sbm->sd[wake][l] will locate the sd of cpu which
> support wake up on level l.
>
> In order to quickly locate the lower sd while changing the base cpu,
> the level with empty sd in map will be filled with the lower sd.
>
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
> ---
> kernel/sched/core.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++
> kernel/sched/sched.h | 28 +++++++++++++++++++++++
> 2 files changed, 89 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 2d8927f..80810a3 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5497,6 +5497,55 @@ static void update_top_cache_domain(int cpu)
> per_cpu(sd_llc_id, cpu) = id;
> }
>
> +DEFINE_PER_CPU_SHARED_ALIGNED(struct sched_balance_map, sbm_array);
> +
> +static void build_sched_balance_map(int cpu)
> +{
> + struct sched_balance_map *sbm = &per_cpu(sbm_array, cpu);
> + struct sched_domain *sd = cpu_rq(cpu)->sd;
> + struct sched_domain *top_sd = NULL;
> + int i, type, level = 0;
> +
> + while (sd) {
> + if (sd->flags & SD_LOAD_BALANCE) {
> + if (sd->flags & SD_BALANCE_EXEC) {
> + sbm->top_level[SBM_EXEC_TYPE] = sd->level;
> + sbm->sd[SBM_EXEC_TYPE][sd->level] = sd;
> + }
> +
> + if (sd->flags & SD_BALANCE_FORK) {
> + sbm->top_level[SBM_FORK_TYPE] = sd->level;
> + sbm->sd[SBM_FORK_TYPE][sd->level] = sd;
> + }
> +
> + if (sd->flags & SD_BALANCE_WAKE) {
> + sbm->top_level[SBM_WAKE_TYPE] = sd->level;
> + sbm->sd[SBM_WAKE_TYPE][sd->level] = sd;
> + }
> +
> + if (sd->flags & SD_WAKE_AFFINE) {
> + for_each_cpu(i, sched_domain_span(sd)) {
> + if (!sbm->affine_map[i])
> + sbm->affine_map[i] = sd;
> + }
> + }
> + }
> + sd = sd->parent;
> + }
It seems that it can be done like:
for_each_domain(cpu, sd) {
if (!(sd->flags & SD_LOAD_BALANCE))
continue;
if (sd->flags & SD_BALANCE_EXEC)
...
}
> +
> + /*
> + * fill the hole to get lower level sd easily.
> + */
> + for (type = 0; type < SBM_MAX_TYPE; type++) {
> + level = sbm->top_level[type];
> + top_sd = sbm->sd[type][level];
> + if ((++level != SBM_MAX_LEVEL) && top_sd) {
> + for (; level < SBM_MAX_LEVEL; level++)
> + sbm->sd[type][level] = top_sd;
> + }
> + }
> +}
[snip]
> +#ifdef CONFIG_SCHED_SMT
> +#define SBM_MAX_LEVEL 4
> +#else
> +#ifdef CONFIG_SCHED_MC
> +#define SBM_MAX_LEVEL 3
> +#else
> +#ifdef CONFIG_SCHED_BOOK
> +#define SBM_MAX_LEVEL 2
> +#else
> +#define SBM_MAX_LEVEL 1
> +#endif
> +#endif
> +#endif
Looks like this fixed level constants does not consider NUMA domains.
Doesn't accessing sbm->sd[type][level] in the above while loop cause a
problem on big NUMA machines?
Thanks,
Namhyung
> +
> +enum {
> + SBM_EXEC_TYPE,
> + SBM_FORK_TYPE,
> + SBM_WAKE_TYPE,
> + SBM_MAX_TYPE
> +};
> +
> +struct sched_balance_map {
> + struct sched_domain *sd[SBM_MAX_TYPE][SBM_MAX_LEVEL];
> + int top_level[SBM_MAX_TYPE];
> + struct sched_domain *affine_map[NR_CPUS];
> +};
> +
> #endif /* CONFIG_SMP */
>
> /*
> @@ -403,6 +430,7 @@ struct rq {
> #ifdef CONFIG_SMP
> struct root_domain *rd;
> struct sched_domain *sd;
> + struct sched_balance_map *sbm;
>
> unsigned long cpu_power;
next prev parent reply other threads:[~2013-01-14 8:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-11 8:15 [RFC PATCH 0/2] sched: simplify the select_task_rq_fair() Michael Wang
2013-01-11 8:17 ` [RFC PATCH 1/2] sched: schedule balance map foundation Michael Wang
2013-01-14 8:26 ` Namhyung Kim [this message]
2013-01-15 2:33 ` Michael Wang
2013-01-11 8:18 ` [RFC PATCH 2/2] sched: simplify select_task_rq_fair() with schedule balance map Michael Wang
2013-01-14 8:27 ` Namhyung Kim
2013-01-15 2:33 ` Michael Wang
2013-01-11 10:13 ` [RFC PATCH 0/2] sched: simplify the select_task_rq_fair() Nikunj A Dadhania
2013-01-15 2:20 ` Michael Wang
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=87libwnpa7.fsf@sejong.aot.lge.com \
--to=namhyung@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pjt@google.com \
--cc=tj@kernel.org \
--cc=wangyun@linux.vnet.ibm.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.