All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Wang <wangyun@linux.vnet.ibm.com>
To: Namhyung Kim <namhyung@kernel.org>
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: Tue, 15 Jan 2013 10:33:09 +0800	[thread overview]
Message-ID: <50F4BFE5.7030504@linux.vnet.ibm.com> (raw)
In-Reply-To: <87libwnpa7.fsf@sejong.aot.lge.com>

Hi, Namhyung

Thanks for your reply.

On 01/14/2013 04:26 PM, Namhyung Kim wrote:
> Hi Michael,
> 

[snip]

>> +	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)
> 		...
> 	}
> 
> 

That's right, will correct it.

>> +
>> +	/*
>> +	 * 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?

Yes, that's true, this patch is based on 3.7.0-rc6 without NUMA merged,
in order to make the topic a little easier to be started, I will
consider about the NUMA thing in next version, and please let me know if
you have any suggestions.

Regards,
Michael Wang

> 
> 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;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2013-01-15  2:33 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
2013-01-15  2:33     ` Michael Wang [this message]
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=50F4BFE5.7030504@linux.vnet.ibm.com \
    --to=wangyun@linux.vnet.ibm.com \
    --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=namhyung@kernel.org \
    --cc=pjt@google.com \
    --cc=tj@kernel.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 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.