[lkml]   [2016]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] sched/fair: Do not decay new task load on first enqueue
On Tue, 27 Sep, at 02:48:31PM, Dietmar Eggemann wrote:
> I think Matt is talking about the fact that the cfs->runnable_load_avg
> value is 0 once the hackbench task is initially dequeued.


> Without this patch the value of se->avg.load_avg (e.g. both times 1002)
> is exactly the same when we add it to cfs_rq->runnable_load_avg in
> enqueue_entity_load_avg() and when we subtract it in
> dequeue_entity_load_avg(). That's because the initial runtime is short
> (~250us on my hikey board).
> With this patch we add 1024 and subtract ~1002 which lets
> cfs_rq->runnable_load_avg still have a small positive value. This
> favours that for the next hackbench task another cpu will be chosen in
> (load-based) fork-balance.

Bingo, that's exactly it. Sorry if i was unclear.

 \ /
  Last update: 2016-09-27 21:24    [W:0.054 / U:9.748 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site