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: <20140729230829.GB28673@intel.com>
Date:	Wed, 30 Jul 2014 07:08:29 +0800
From:	Yuyang Du <yuyang.du@...el.com>
To:	Peter Zijlstra <peterz@...radead.org>
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 03:35:10PM +0200, Peter Zijlstra wrote:
> 
> 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.

I am not sure I understand your example, but it seems it is group weight
distribution. Since in migration, we migrate the load with task, 170 will be
utterly moved. So the new weight/share distribution would be immediate
512 and 512.

But for the group entity's parent cfs_rq in terms of how this group entity
contributes to load in the infinite decaying series, it would be
e.g., 341 and before, migration, then 512 thereafter.

Hope this graph helps:

CPU1 <--> cfs_rq1                         CPU2 <--> cfs_rq2
             |                                         |
      |------------|                            |------------|
tsk_entity1   tg_entity1 <--> tg_cfs_rq1  tsk_entity2   tg_entity2 <--> tg_cfs_rq2
                                  |                                         |
                            tsk_entity3                               tsk_entity4

Then On CPU1:

cfs_rq1->avg.load_avg = tsk_entity1->avg.load_avg + tg_entity1->avg.load_avg

tg_cfs_rq1->avg.load_avg = tsk_entity3->avg.load_avg

tg_entity1's weight = tg_cfs_rq1->avg.load_avg / (tg_cfs_rq1->avg.load_avg + tg_cfs_rq2->avg.load_avg)

Same for things on CPU2.

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