{"push_id":1335141570,"size":1,"distinct_size":1,"ref":"refs/heads/my-MM-v10c-linux-3.18.y-kernel","head":"1e401387a86ae0568f482d8d8b38d55c50cbcbd8","before":"1a3e1f441900aff7d6c558b412e6c3b2f7c6c15c","commits":[{"sha":"1e401387a86ae0568f482d8d8b38d55c50cbcbd8","author":{"name":"Dietmar Eggemann","email":"7bef2e184847c39785107604e3ad072c9e462174@arm.com"},"message":"sched/fair: Make utilization tracking CPU scale-invariant\n\nBesides the existing frequency scale-invariance correction factor, apply\nCPU scale-invariance correction factor to utilization tracking to\ncompensate for any differences in compute capacity. This could be due to\nmicro-architectural differences (i.e. instructions per seconds) between\ncpus in HMP systems (e.g. big.LITTLE), and/or differences in the current\nmaximum frequency supported by individual cpus in SMP systems. In the\nexisting implementation utilization isn't comparable between cpus as it\nis relative to the capacity of each individual CPU.\n\nEach segment of the sched_avg.util_sum geometric series is now scaled\nby the CPU performance factor too so the sched_avg.util_avg of each\nsched entity will be invariant from the particular CPU of the HMP/SMP\nsystem on which the sched entity is scheduled.\n\nWith this patch, the utilization of a CPU stays relative to the max CPU\nperformance of the fastest CPU in the system.\n\nIn contrast to utilization (sched_avg.util_sum), load\n(sched_avg.load_sum) should not be scaled by compute capacity. The\nutilization metric is based on running time which only makes sense when\ncpus are _not_ fully utilized (utilization cannot go beyond 100% even if\nmore tasks are added), where load is runnable time which isn't limited\nby the capacity of the CPU and therefore is a better metric for\noverloaded scenarios. If we run two nice-0 busy loops on two cpus with\ndifferent compute capacity their load should be similar since their\ncompute demands are the same. We have to assume that the compute demand\nof any task running on a fully utilized CPU (no spare cycles = 100%\nutilization) is high and the same no matter of the compute capacity of\nits current CPU, hence we shouldn't scale load by CPU capacity.\n\nSigned-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>\nSigned-off-by: Morten Rasmussen <morten.rasmussen@arm.com>\nSigned-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Mike Galbraith <efault@gmx.de>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nLink: http://lkml.kernel.org/r/55CE7409.1000700@arm.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n\n(cherry picked from commit e3279a2e6d697e00e74f905851ee7cf532f72b2d)\nSigned-off-by: Ricky Liang <jcliang@chromium.org>\n\nConflicts:\n\tkernel/sched/fair.c","distinct":true,"url":"https://api.github.com/repos/Alucard24/Alucard-Kernel-LG-G5/commits/1e401387a86ae0568f482d8d8b38d55c50cbcbd8"}]}
{"actor":{"display_login":"Alucard24"}}