On Tue, Nov 19, 2013 at 01:19:51PM +0000, Alex Shi wrote:
On 11/19/2013 08:45 PM, Morten Rasmussen wrote:
On Tue, Nov 19, 2013 at 11:46:19AM +0000, Alex Shi wrote:
We know the load_idx is a decay for cpu_load of rq. After added sched_avg, we has 2 kind decay for cpu_load. That is a kind of redundancy.
This patch remove the load_idx. There are 5 _idx in sched_domain, busy_idx and idle_idx are not zero usually, but newidle_idx, wake_idx and forkexec_idx are all zero on all arch. and this patch remove the only place using busy_idx/idle_idx.
Have you looked into the decay rates of cpu_load[busy_idx] and cpu_load[idle_idx] and compared them to the load in sched_avg?
The sched_avg decay according to active task load history. The cpu_load decay on past cpu load: load = (2^idx - 1) / 2^idx * load + 1 / 2^idx * cur_load These 2 cpu load both decay on time. but sched_avg is a bit more precise.
If I understand the code correctly, idx=0 is the unmodified cpu load from sched_avg. idx=1 is slightly slower reacting (longer decay), but still based on the cpu_load from sched_avg. idx=2 is even slower and so on.
I'm thinking that there must be a reason why they are not all using the same average cpu load.
I asked this for PeterZ. PeterZ had no clear answerer of cpu_load decay usage, and he also thought is these 2 decay have a bit redundance.
As to cpu_load decay, it only used in load_balance. to bias on source cpu or no bias.
Yes. Changing it to use idx=0 (sched_avg cpu_load) probably doesn't change things significantly. I may cause load-balance to become a bit more responsive, which can be both good and bad depending on the workload.
Since arm system rarely has much tasks running in system. this removing
Could you elaborate on the effect of this change?
I don't think the assumption that ARM systems rarely have many tasks running is generally valid. Smartphones do occasionally use all available cpus and ARM systems are used in many other segments.
I only has a panda board in hands, and don't know which benchmark are good for the testing. The key of this patch effect is testing. Anyone like to give a hand on this?
AFAIK, there are no theory can prove which decay is better (but obviously, community prefer to sched_avg, since it was added when cpu_load already existed.)
cpu_load is already based on sched_avg either directly (idx=0) or derrived from it. Essentially, this is all about whether we can get rid of the derrived cpu loads.
Also, this patch will affect all architectures, so we need to ensure that none of them are affected negatively.
Yes, so however detailed we measured on ARM, there must are still much testing/comments on this in community. Anyway, I had tested this patch in Intel platforms, and in fengguang's 0day kernel testing. there are no clear regression, also no clear improvement.
OK. I would not expect to see much difference either. Maybe for workloads that vary in load over time and use many tasks. Some Android workloads, like bbench, have this behaviour.
Morten