{"push_id":964292814,"size":3,"distinct_size":3,"ref":"refs/heads/android-6.0","head":"91175c7bafbba4fa4a85eff525249817d30a516d","before":"194d0eaaa3da44b1a54e4459c5c9b95a00ff1d27","commits":[{"sha":"edbd79ef0503a3ffc0f12b0bc9fc2fff28e1c984","author":{"email":"645ca7d3a8d3d4f60557176cd361ea8351edc32b@chello.nl","name":"Peter Zijlstra"},"message":"sched/fair: Improve the ->group_imb logic\n\nGroup imbalance is meant to deal with situations where affinity masks\nand sched domains don't align well, such as 3 cpus from one group and\n6 from another. In this case the domain based balancer will want to\nput an equal amount of tasks on each side even though they don't have\nequal cpus.\n\nCurrently group_imb is set whenever two cpus of a group have a weight\ndifference of at least one avg task and the heaviest cpu has at least\ntwo tasks. A group with imbalance set will always be picked as busiest\nand a balance pass will be forced.\n\nThe problem is that even if there are no affinity masks this stuff can\ntrigger and cause weird balancing decisions, eg. the observed\nbehaviour was that of 6 cpus, 5 had 2 and 1 had 3 tasks, due to the\ndifference of 1 avg load (they all had the same weight) and nr_running\nbeing >1 the group_imbalance logic triggered and did the weird thing\nof pulling more load instead of trying to move the 1 excess task to\nthe other domain of 6 cpus that had 5 cpu with 2 tasks and 1 cpu with\n1 task.\n\nCurb the group_imbalance stuff by making the nr_running condition\nweaker by also tracking the min_nr_running and using the difference in\nnr_running over the set instead of the absolute max nr_running.\n\nSigned-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nLink: http://lkml.kernel.org/n/tip-9s7dedozxo8kjsb9kqlrukkf@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n\nConflicts:\n\n\tkernel/sched/fair.c\n\n(adapter for the latest idle_balance changes)\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/edbd79ef0503a3ffc0f12b0bc9fc2fff28e1c984"},{"sha":"9cfa6ac16921a02bee710a317639cba5d7e5f96d","author":{"email":"3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","name":"Peter Zijlstra"},"message":"sched: Remove stale power aware scheduling remnants and dysfunctional knobs\n\nIt's been broken forever (i.e. it's not scheduling in a power\naware fashion), as reported by Suresh and others sending\npatches, and nobody cares enough to fix it properly ...\nso remove it to make space free for something better.\n\nThere's various problems with the code as it stands today, first\nand foremost the user interface which is bound to topology\nlevels and has multiple values per level. This results in a\nstate explosion which the administrator or distro needs to\nmaster and almost nobody does.\n\nFurthermore large configuration state spaces aren't good, it\nmeans the thing doesn't just work right because it's either\nunder so many impossibe to meet constraints, or even if\nthere's an achievable state workloads have to be aware of\nit precisely and can never meet it for dynamic workloads.\n\nSo pushing this kind of decision to user-space was a bad idea\neven with a single knob - it's exponentially worse with knobs\non every node of the topology.\n\nThere is a proposal to replace the user interface with a single\n3 state knob:\n\n sched_balance_policy := { performance, power, auto }\n\nwhere 'auto' would be the preferred default which looks at things\nlike Battery/AC mode and possible cpufreq state or whatever the hw\nexposes to show us power use expectations - but there's been no\nprogress on it in the past many months.\n\nAside from that, the actual implementation of the various knobs\nis known to be broken. There have been sporadic attempts at\nfixing things but these always stop short of reaching a mergable\nstate.\n\nTherefore this wholesale removal with the hopes of spurring\npeople who care to come forward once again and work on a\ncoherent replacement.\n\nSigned-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nCc: Suresh Siddha <suresh.b.siddha@intel.com>\nCc: Arjan van de Ven <arjan@linux.intel.com>\nCc: Vincent Guittot <vincent.guittot@linaro.org>\nCc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Andrew Morton <akpm@linux-foundation.org>\nLink: http://lkml.kernel.org/r/1326104915.2442.53.camel@twins\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\n\nConflicts:\n\tkernel/sched/core.c","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/9cfa6ac16921a02bee710a317639cba5d7e5f96d"},{"sha":"91175c7bafbba4fa4a85eff525249817d30a516d","author":{"email":"22097694d54958bd3c75f6e60b2c5bd5c9ed5db4@yahoo.es","name":"kabata1975"},"message":"Fix sched: Remove stale power aware scheduling remnants and dysfunctional… Xs","distinct":true,"url":"https://api.github.com/repos/kabata1975/android_kernel_lge_hammerhead/commits/91175c7bafbba4fa4a85eff525249817d30a516d"}]}