Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1492116
| 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-7@gated-at.bofh.it> (permalink) |
| References | <skxj3-38t-3@gated-at.bofh.it> <skzNT-4QO-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, 23 Sep, at 04:30:25PM, Vincent Guittot wrote: > > Does it mean that you can see the perf drop that you mention below > because load is decayed to 1002 instead of staying to 1024 ? The performance drop comes from the fact that enqueueing/dequeueing a task with load 1002 during fork() results in a zero runnable_load_avg, which signals to the load balancer that the CPU is idle, so the next time we fork() we'll pick the same CPU to enqueue on -- and the cycle continues. I mention the performance regression mainly because it's the thing that led to me discovering this bug, and only a little as support for applying the patch ;-) > 1002 mainly comes from period_contrib being set to 1023 during > init_entity_runnable_average so any delay longer than 1us between > attach_entity_load_avg and enqueue_entity_load_avg will trig the decay > of the load from 1024 to 1002 Right. > But this patch doesn't change the behavior of runnable_load_avg, isn't > it ? it has only an impact on the initial value of p->se.avg.load_avg > when the task is enqueued. Correct. It isn't guaranteed that runnable_load_avg will be non-zero with this patch applied, that was just the case for the workload and the machine I tested. > > Arguably the real problem is that balancing on fork doesn't look at > > the blocked contribution of tasks, only the runnable load and it's > > possible for the two metrics to be wildly different on a relatively > > idle system. > > fair enough I did have some patches somewhere to address this. I'll have to dig them out.
Back to linux.kernel | Previous | Next — Previous 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