linux-kernel - Re: [PATCH 2/2 v4] sched: Rewrite per entity runnable load average tracking

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: <20140729133510.GF3935@laptop>
Date:	Tue, 29 Jul 2014 15:35:10 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Yuyang Du <yuyang.du@...el.com>
Cc:	Vincent Guittot <vincent.guittot@...aro.org>,
	"mingo@...hat.com" <mingo@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Paul Turner <pjt@...gle.com>,
	Benjamin Segall <bsegall@...gle.com>,
	arjan.van.de.ven@...el.com, Len Brown <len.brown@...el.com>,
	rafael.j.wysocki@...el.com, alan.cox@...el.com,
	"Gross, Mark" <mark.gross@...el.com>,
	"fengguang.wu@...el.com" <fengguang.wu@...el.com>
Subject: Re: [PATCH 2/2 v4] sched: Rewrite per entity runnable load average
 tracking

On Tue, Jul 29, 2014 at 09:53:44AM +0800, Yuyang Du wrote:
> On Tue, Jul 29, 2014 at 11:39:11AM +0200, Peter Zijlstra wrote:
> > > > For task, assuming its load.weight does not change much, yes, we can. But in theory, task's
> > > 
> > > I would even say that the load_avg of a task should not be impacted by
> > > an old priority value. Once, the priority of a task is changed, we
> > > should only take into account this new priority to weight the load_avg
> > > of the task
> > 
> > So for tasks I would immediately agree, and I think for groups too,
> > seeing how the group weight is based off of this avg, if you then
> > include the old weight we'll get a feedback loop. This might not be
> > desired as it would counteract the SMP movement of tasks.
> 
> Including the old weight can we get the *right* feedback. Because say until
> weight is changed, we are balanced, changed weight leads to imbalance. Without
> old weight, the imbalance is multiplied by the history, like we have never been
> balanced.

Does not compute, sorry. How would delaying the effect of migrations
help?

Suppose we have 2 cpus and 6 tasks. cpu0 has 2 tasks, cpu1 has 4 tasks.
the group weights are resp. 341 and 682. We compute we have an imbalance
of 341 and need to migrate 170 to equalize. We achieve this by moving
the 1 task, such that both cpus end up with 4 tasks.

After that we want to find weights of 512 and 512. But if we were to
consider old weights, we'd find 426 and 597 making it appear there is
still an imbalance. We could end up migrating more, only to later find
we overshot and now need to go back.

This is the classical ringing problem.

I also don't see any up-sides from doing this.
--
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/