lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 19 Mar 2014 11:51:54 +0530
From:	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
To:	Vincent Guittot <vincent.guittot@...aro.org>
CC:	peterz@...radead.org, mingo@...nel.org,
	linux-kernel@...r.kernel.org, dietmar.eggemann@....com,
	tony.luck@...el.com, fenghua.yu@...el.com, schwidefsky@...ibm.com,
	james.hogan@...tec.com, cmetcalf@...era.com,
	benh@...nel.crashing.org, linux@....linux.org.uk,
	linux-arm-kernel@...ts.infradead.org,
	linaro-kernel@...ts.linaro.org
Subject: Re: [PATCH v2 5/7] sched: add a new SD_SHARE_POWERDOMAIN for sched_domain

Hi Vincent,

On 03/18/2014 11:26 PM, Vincent Guittot wrote:
> A new flag SD_SHARE_POWERDOMAIN is created to reflect whether groups of CPUs
> in a sched_domain level can or not reach different power state. As an example,
> the flag should be cleared at CPU level if groups of cores can be power gated
> independently. This information can be used to add load balancing level between
> group of CPUs than can power gate independantly. The default behavior of the
> scheduler is to spread tasks across CPUs and groups of CPUs so the flag is set
> into all sched_domains.

I don't see this flag being set either in sd_init() or in
default_topology[]. Should not the default_topology[] flag setting
routines set this flag at every level of sched domain along with other
topology flags, unless the arch wants to override it?

Regards
Preeti U Murthy
> This flag is part of the topology flags that can be set by arch.
> 
> Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
> ---
>  include/linux/sched.h | 1 +
>  kernel/sched/core.c   | 9 ++++++---
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 6479de4..7048369 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -861,6 +861,7 @@ enum cpu_idle_type {
>  #define SD_BALANCE_WAKE		0x0010  /* Balance on wakeup */
>  #define SD_WAKE_AFFINE		0x0020	/* Wake task to waking CPU */
>  #define SD_SHARE_CPUPOWER	0x0080	/* Domain members share cpu power */
> +#define SD_SHARE_POWERDOMAIN	0x0100	/* Domain members share power domain */
>  #define SD_SHARE_PKG_RESOURCES	0x0200	/* Domain members share cpu pkg resources */
>  #define SD_SERIALIZE		0x0400	/* Only a single load balancing instance */
>  #define SD_ASYM_PACKING		0x0800  /* Place busy groups earlier in the domain */
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 0b51ee3..224ec3b 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5298,7 +5298,8 @@ static int sd_degenerate(struct sched_domain *sd)
>  			 SD_BALANCE_FORK |
>  			 SD_BALANCE_EXEC |
>  			 SD_SHARE_CPUPOWER |
> -			 SD_SHARE_PKG_RESOURCES)) {
> +			 SD_SHARE_PKG_RESOURCES |
> +			 SD_SHARE_POWERDOMAIN)) {
>  		if (sd->groups != sd->groups->next)
>  			return 0;
>  	}
> @@ -5329,7 +5330,8 @@ sd_parent_degenerate(struct sched_domain *sd, struct sched_domain *parent)
>  				SD_BALANCE_EXEC |
>  				SD_SHARE_CPUPOWER |
>  				SD_SHARE_PKG_RESOURCES |
> -				SD_PREFER_SIBLING);
> +				SD_PREFER_SIBLING |
> +				SD_SHARE_POWERDOMAIN);
>  		if (nr_node_ids == 1)
>  			pflags &= ~SD_SERIALIZE;
>  	}
> @@ -5946,7 +5948,8 @@ static int sched_domains_curr_level;
>  	(SD_SHARE_CPUPOWER |		\
>  	 SD_SHARE_PKG_RESOURCES |	\
>  	 SD_NUMA |			\
> -	 SD_ASYM_PACKING)
> +	 SD_ASYM_PACKING |		\
> +	 SD_SHARE_POWERDOMAIN)
> 
>  static struct sched_domain *
>  sd_init(struct sched_domain_topology_level *tl, int cpu)
> 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ