Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1492114
| From | Matt Fleming <matt@codeblueprint.co.uk> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] sched/fair: Do not decay new task load on first enqueue |
| Date | 2016-09-27 21:30 +0200 |
| Message-ID | <sm6eK-55p-9@gated-at.bofh.it> (permalink) |
| References | <skxj3-38t-3@gated-at.bofh.it> <skzNT-4QO-13@gated-at.bofh.it> <sm0VH-1H1-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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. Yes. > 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.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH] sched/fair: Do not decay new task load on first enqueue Vincent Guittot <vincent.guittot@linaro.org> - 2016-09-23 16:40 +0200
Re: [PATCH] sched/fair: Do not decay new task load on first enqueue Dietmar Eggemann <dietmar.eggemann@arm.com> - 2016-09-27 15:50 +0200
Re: [PATCH] sched/fair: Do not decay new task load on first enqueue Matt Fleming <matt@codeblueprint.co.uk> - 2016-09-27 21:30 +0200
Re: [PATCH] sched/fair: Do not decay new task load on first enqueue Matt Fleming <matt@codeblueprint.co.uk> - 2016-09-27 21:30 +0200
csiph-web