linux-kernel - Re: [wake_afine fixes/improvements 1/3] sched: update effective

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:	Mon, 17 Jan 2011 15:11:37 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Paul Turner <pjt@...gle.com>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Mike Galbraith <efault@....de>,
	Nick Piggin <npiggin@...nel.dk>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Subject: Re: [wake_afine fixes/improvements 1/3] sched: update
 effective_load() to use global share weights

On Fri, 2011-01-14 at 17:57 -0800, Paul Turner wrote:
> plain text document attachment (fix_wake_affine.patch)
> Previously effective_load would approximate the global load weight present on
> a group taking advantage of:
> 
> entity_weight = tg->shares ( lw / global_lw ), where entity_weight was provided
> by tg_shares_up.
> 
> This worked (approximately) for an 'empty' (at tg level) cpu since we would
> place boost load representative of what a newly woken task would receive.
> 
> However, now that load is instantaneously updated this assumption is no longer
> true and the load calculation is rather incorrect in this case.
> 
> Fix this (and improve the general case) by re-writing effective_load to take
> advantage of the new shares distribution code.
> 
> Signed-off-by: Paul Turner <pjt@...gle.com>
> 
> ---
>  kernel/sched_fair.c |   32 ++++++++++++++++----------------
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> Index: tip3/kernel/sched_fair.c
> ===================================================================
> --- tip3.orig/kernel/sched_fair.c
> +++ tip3/kernel/sched_fair.c
> @@ -1362,27 +1362,27 @@ static long effective_load(struct task_g
>  		return wl;
>  
>  	for_each_sched_entity(se) {
> +		long lw, w;
>  
> +		tg = se->my_q->tg;
> +		w = se->my_q->load.weight;

weight of this cpu's part of the task-group

> +		/* use this cpu's instantaneous contribution */
> +		lw = atomic_read(&tg->load_weight);
> +		lw -= se->my_q->load_contribution;
> +		lw += w + wg;

total weight of this task_group + new load
 
> +		wl += w;

this cpu's weight + new load

> +		if (lw > 0 && wl < lw)
> +			wl = (wl * tg->shares) / lw;
> +		else
> +			wl = tg->shares;

OK, so this computes the new load for this cpu, by taking the
appropriate proportion of tg->shares, it clips on large wl, and does
something funny for !lw -- on purpose?


> +		/* zero point is MIN_SHARES */
> +		if (wl < MIN_SHARES)
> +			wl = MIN_SHARES;

*nod*

> +		wl -= se->load.weight;

Take the weight delta up to the next level..

>  		wg = 0;

And assume all further groups are already enqueued and stay enqueued.

>  	}




 
--
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/