linux-kernel - Re: [PATCH 5/5] Only call rebalance_domains when needed from scheduler

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:	Thu, 26 Oct 2006 11:13:11 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
cc:	akpm@...l.org, Peter Williams <pwil3058@...pond.net.au>,
	linux-kernel@...r.kernel.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Dave Chinner <dgc@....com>, Ingo Molnar <mingo@...e.hu>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>
Subject: Re: [PATCH 5/5] Only call rebalance_domains when needed from
 scheduler_tick

On Fri, 27 Oct 2006, Nick Piggin wrote:

> > > sched-domains was supposed to be able to build a whacky topology
> > > so you didn't have to take the occasional big latency hit when
> > > scanning 512 CPUs...
> > 
> > 
> > How is that supposed to work? The load calculations will be off
> > in that case and also the load balancing algorithm wont work anymore. This
> > is going to be a pretty significant rework of how the scheduler works but
> > given the problems with pinned tasks... maybe that is necessary?
> > duler?
> 
> What will the problem be? Sure it may pull tasks fom one group to
> another when both could actually be pulling from a third, but it
> the load balancing algorithm should work fine and not require any
> rework.

Hmmm....
I think we already have what you want if we would disable the allnodes 
domain. The next sched domain layer contains 16 surrounding nodes 
from which it can pull processes. If there would be severe overload on one 
node  then processes would be gradually migrated away from it but it would 
require multiple migration steps.

Nevertheless, I still think we need this patchset because of the general 
interrupt hold off issue. The livelock is extreme case but it general we 
do no want long interrupt holdoffs but keep the period in which we would 
be executing with interrupts off minimal.

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