linux-kernel - Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

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, 28 Sep 2016 18:59:52 +0100
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Matt Fleming <matt@...eblueprint.co.uk>,
        Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
        Mike Galbraith <umgwanakikbuti@...il.com>,
        Yuyang Du <yuyang.du@...el.com>,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue

On 28/09/16 12:19, Peter Zijlstra wrote:
> On Wed, Sep 28, 2016 at 12:06:43PM +0100, Dietmar Eggemann wrote:
>> On 28/09/16 11:14, Peter Zijlstra wrote:
>>> On Fri, Sep 23, 2016 at 12:58:08PM +0100, Matt Fleming wrote:

[...]

>> I'm afraid that with accurate timing we will get the same situation that
>> we add and subtract the same amount of load (probably 1024 now and not
>> 1002 (or less)) to/from cfs_rq->runnable_load_avg for the initial (fork)
>> hackbench run.
>> After all, it's 'runnable' based.
> 
> The idea was that since we now update rq clock before post_init and then
> leave it be, both post_init and enqueue see the exact same timestamp,
> and the delta is 0, resulting in no aging.
> 
> Or did I fail to make that happen?

No, you're right the task load ages from 1024 (enqueue) to something
between 1002 and 1024 in (dequeue) for the initial fork-phase.

The call to __update_load_avg() in enqueue_task_fair() is now always
done with 'delta = now - sa->last_update_time' equal 0 so we bail out.

The following call to __update_load_avg() (from dequeue_task_fair(), or
set_next_entity() or even task_tick_fair()) let us enter the 'decayed =
1' path (even for a short runtime (>1us) since the initial value for
period_contrib is 1023 and with the initial values of load_avg=1024 and
load_sum = 1024*47742 = 48,887,808 (and a runtime < 1001us, so contrib
stays 0) we end up decaying load_avg to something between 1002 and 1024.