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.
