linux-kernel - Re: [PATCH v4] sched: Update runnable propagation rule

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:   Wed, 6 Dec 2017 18:10:24 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Vincent Guittot <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org, Yuyang Du <yuyang.du@...el.com>,
        Mike Galbraith <efault@....de>, Chris Mason <clm@...com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Josef Bacik <josef@...icpanda.com>,
        Ben Segall <bsegall@...gle.com>, Paul Turner <pjt@...gle.com>,
        Tejun Heo <tj@...nel.org>,
        Morten Rasmussen <morten.rasmussen@....com>
Subject: Re: [PATCH v4] sched: Update runnable propagation rule


* Peter Zijlstra <peterz@...radead.org> wrote:

> On Thu, Nov 16, 2017 at 03:21:52PM +0100, Vincent Guittot wrote:
> > Unlike running, the runnable part can't be directly propagated through
> > the hierarchy when we migrate a task. The main reason is that runnable
> > time can be shared with other sched_entities that stay on the rq and
> > this runnable time will also remain on prev cfs_rq and must not be
> > removed.
> > 
> > Instead, we can estimate what should be the new runnable of the prev
> > cfs_rq and check that this estimation stay in a possible range. The
> > prop_runnable_sum is a good estimation when adding runnable_sum but
> > fails most often when we remove it. Instead, we could use the formula
> > below instead:
> > 
> >   gcfs_rq's runnable_sum = gcfs_rq->avg.load_sum / gcfs_rq->load.weight
> > 
> > which assumes that tasks are equally runnable which is not true but
> > easy to compute.
> > 
> > Beside these estimates, we have several simple rules that help us to filter
> > out wrong ones:
> > 
> >  - ge->avg.runnable_sum <= than LOAD_AVG_MAX
> >  - ge->avg.runnable_sum >= ge->avg.running_sum (ge->avg.util_sum << LOAD_AVG_MAX)
> >  - ge->avg.runnable_sum can't increase when we detach a task
> > 
> > Cc: Yuyang Du <yuyang.du@...el.com>
> > Cc: Ingo Molnar <mingo@...nel.org>
> > Cc: Mike Galbraith <efault@....de>
> > Cc: Chris Mason <clm@...com>
> > Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> > Cc: Dietmar Eggemann <dietmar.eggemann@....com>
> > Cc: Josef Bacik <josef@...icpanda.com>
> > Cc: Ben Segall <bsegall@...gle.com>
> > Cc: Paul Turner <pjt@...gle.com>
> > Cc: Tejun Heo <tj@...nel.org>
> > Cc: Morten Rasmussen <morten.rasmussen@....com>
> > Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
> > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> > Link: http://lkml.kernel.org/r/20171019150442.GA25025@linaro.org
> 
> Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>
> 
> Ingo, can you stuff this in sched/urgent ?

Yeah, I've queued up in tip:sched/urgent.

Thanks,

	Ingo