linux-kernel - Re: [PATCH RFC] sched/fair: let cpu's cfs

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:	Tue, 5 Apr 2016 08:15:52 +0800
From:	Yuyang Du <yuyang.du@...el.com>
To:	Morten Rasmussen <morten.rasmussen@....com>
Cc:	Leo Yan <leo.yan@...aro.org>,
	Steve Muckle <steve.muckle@...aro.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-kernel@...r.kernel.org, eas-dev@...ts.linaro.org
Subject: Re: [PATCH RFC] sched/fair: let cpu's cfs_rq to reflect task
 migration

On Tue, Apr 05, 2016 at 08:51:13AM +0100, Morten Rasmussen wrote:
> On Tue, Apr 05, 2016 at 02:30:03AM +0800, Yuyang Du wrote:
> > On Mon, Apr 04, 2016 at 09:48:23AM +0100, Morten Rasmussen wrote:
> > > On Sat, Apr 02, 2016 at 03:11:54PM +0800, Leo Yan wrote:
> > > > On Fri, Apr 01, 2016 at 03:28:49PM -0700, Steve Muckle wrote:
> > > > > I think I follow - Leo please correct me if I mangle your intentions.
> > > > > It's an issue that Morten and Dietmar had mentioned to me as well.
> > > 
> > > Yes. We have been working on this issue for a while without getting to a
> > > nice solution yet.
> >  
> > So do you want a "flat hirarchy" for util_avg - just do util_avg for
> > rq and task respectively? Seems it is what you want, and it is even easier?
> 
> Pretty much, yes. I can't think of a good reason why we need the
> utilization of groups as long as we have the task utilization and the
> sum of those for the root cfs_rq.
 
Sound good to me too.

> I'm not saying it can't be implemented, just saying that it will make
> utilization tracking for groups redundant and possibly duplicate or hack
> some the existing code to implement the new root utilization sum.

A initial evaluation of the implementation: it looks much easier to do (at
least) than the current. Lets wait for a day or two, if no objection, then
lets do it.