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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 26 Feb 2014 09:54:44 +0800
From:	Alex Shi <alex.shi@...aro.org>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
CC:	mingo@...hat.com, peterz@...radead.org, morten.rasmussen@....com,
	vincent.guittot@...aro.org, daniel.lezcano@...aro.org,
	fweisbec@...il.com, linux@....linux.org.uk, tony.luck@...el.com,
	fenghua.yu@...el.com, james.hogan@...tec.com, jason.low2@...com,
	viresh.kumar@...aro.org, hanjun.guo@...aro.org,
	linux-kernel@...r.kernel.org, tglx@...utronix.de,
	akpm@...ux-foundation.org, arjan@...ux.intel.com, pjt@...gle.com,
	fengguang.wu@...el.com, linaro-kernel@...ts.linaro.org,
	wangyun@...ux.vnet.ibm.com, mgorman@...e.de
Subject: Re: [PATCH 02/11] sched: remove rq->cpu_load[load_idx] array

On 02/26/2014 12:22 AM, Srikar Dronamraju wrote:
>>  
>> -/**
>> - * get_sd_load_idx - Obtain the load index for a given sched domain.
>> - * @sd: The sched_domain whose load_idx is to be obtained.
>> - * @idle: The idle status of the CPU for whose sd load_idx is obtained.
>> - *
>> - * Return: The load index.
>> - */
>> -static inline int get_sd_load_idx(struct sched_domain *sd,
>> -					enum cpu_idle_type idle)
>> -{
>> -	int load_idx;
>> -
>> -	switch (idle) {
>> -	case CPU_NOT_IDLE:
>> -		load_idx = sd->busy_idx;
>> -		break;
>> -
>> -	case CPU_NEWLY_IDLE:
>> -		load_idx = sd->newidle_idx;
>> -		break;
>> -	default:
>> -		load_idx = sd->idle_idx;
>> -		break;
>> -	}
>> -
>> -	return load_idx;
>> -}
>> -
> 
> Since the last caller to get_sd_load_idx(), does it make sense to remove
> the function definition for get_sd_load_idx() in the previous patch itself?

yes. it's reasonable.
> 
> Or
> 
>> @@ -5903,13 +5868,11 @@ static inline void update_sd_lb_stats(struct lb_env *env, struct sd_lb_stats *sd
>>  	struct sched_domain *child = env->sd->child;
>>  	struct sched_group *sg = env->sd->groups;
>>  	struct sg_lb_stats tmp_sgs;
>> -	int load_idx, prefer_sibling = 0;
>> +	int prefer_sibling = 0;
>>  
>>  	if (child && child->flags & SD_PREFER_SIBLING)
>>  		prefer_sibling = 1;
>>  
>> -	load_idx = 0;
>> -
>>  	do {
>>  		struct sg_lb_stats *sgs = &tmp_sgs;
>>  		int local_group;
> 
> 
> The single line change in the previous patch gets removed here so why
> not club them.

Uh, the first patch want to just show the load_idx connection in current
logical.

Yes, we can club them, but this connection will be flooded in code.



-- 
Thanks
    Alex
--
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