linux-kernel - Re: + sched-use-tasklet-to-call-balancing.patch added to -mm tree

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]

Message-ID: <20061110214208.GA23456@elte.hu>
Date:	Fri, 10 Nov 2006 22:42:08 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Christoph Lameter <clameter@....com>
Cc:	"Chen, Kenneth W" <kenneth.w.chen@...el.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>, akpm@...l.org,
	mm-commits@...r.kernel.org, nickpiggin@...oo.com.au,
	linux-kernel@...r.kernel.org
Subject: Re: + sched-use-tasklet-to-call-balancing.patch added to -mm tree

* Christoph Lameter <clameter@....com> wrote:

> On a 8p system:
> 
> I) Percent of ticks where load balancing was found to be required
> 
> II) Percent of ticks where we attempted load balancing
>    but we found that we need to try again due to load balancing
>    in progress elsewhere (This increases (I) since we found that
>    load balancing was required but we decided to defer. Tasklet
>    was not invoked).
> 
>     	I)	II) 
> Boot:	70%	~1%
> AIM7:	30%	2%
> Idle:	50%	 <0.5%
> 
> 256p:
> 	I)	II)
> Boot:	80%	30%
> AIM7:	90%	30%
> Idle: 	95%	30%

nice measurements and interesting results.

note that with a tasklet a 'retry' will often be done on the /same/ CPU 
that was running the tasklet when we tried to schedule it. I.e. such a 
'collision' will result not only in the 'loss' of the local rebalance 
event, but also causes /another/ rebalance event on the remote CPU.

so a better model would be the trylock model i suggested in the previous 
mail: to just lose the rebalance events upon collision and not cause 
extra work on the remote CPU. I'd also suggest to keep the rebalancing 
code under the irqs-off section, like it is currently - only do it 
conditional on trylock success. Do you think that would work?

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