linux-kernel - Re: [patch 00/16] sched: per-entity load-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: <xm26zk4fbats.fsf@sword-of-the-dawn.mtv.corp.google.com>
Date:	Mon, 24 Sep 2012 10:16:31 -0700
From:	Benjamin Segall <bsegall@...gle.com>
To:	Jan H. Schönherr <schnhrr@...tu-berlin.de>
Cc:	pjt@...gle.com, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	Venki Pallipadi <venki@...gle.com>,
	Mike Galbraith <efault@....de>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Nikunj A Dadhania <nikunj@...ux.vnet.ibm.com>,
	Morten Rasmussen <Morten.Rasmussen@....com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Namhyung Kim <namhyung@...nel.org>
Subject: Re: [patch 00/16] sched: per-entity load-tracking

"Jan H. Schönherr" <schnhrr@...tu-berlin.de> writes:

> Hi Paul.
>
> Am 23.08.2012 16:14, schrieb pjt@...gle.com:
>> Please find attached the latest version for CFS load-tracking.
>
> Originally, I thought, this series also takes care of
> the leaf-cfs-runqueue ordering issue described here:
>
> http://lkml.org/lkml/2011/7/18/86
>
> Now, that I had a closer look, I see that it does not take
> care of it.
>
> Is there still any reason why the leaf_cfs_rq-list must be sorted?
> Or could we just get rid of the ordering requirement, now?

Ideally yes, since a parent's __update_cfs_rq_tg_load_contrib and
update_cfs_shares still depend on accurate values in
runnable_load_avg/blocked_load_avg from its children. That said, nothing
should completely fall over, it would make load decay take longer to
propogate to the root.
>
> (That seems easier than to fix the issue, as I suspect that
> __update_blocked_averages_cpu() might still punch some holes
> in the hierarchy in some edge cases.)

Yeah, I suspect it's possible that the parent ends up with a slightly
lower runnable_avg_sum if they're both hovering around the max value
since it isn't quite continuous, and it might be the case that this
difference is large enough to require one more tick to decay to zero.
--
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/