{"push_id":2985289693,"size":8,"distinct_size":8,"ref":"refs/heads/eas/neutrino-msm-mata-4.4","head":"5c1f09baa8972f17ed035829fe6a24145aba32b1","before":"61a1fc8648cec2061fb1f7f72220ab3da8e0b247","commits":[{"sha":"3847c81a1b7a25b22a0a6c0b7aca76d79388b418","author":{"name":"Nathan Chancellor","email":"f65d3f2dc139dcfe7b6f0b0a466af3bc5fed8fa7@gmail.com"},"message":"sched: Turn on SCHEDTUNE_BOOST_HOLD_ALL\n\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/0ctobot/neutrino-staging/commits/3847c81a1b7a25b22a0a6c0b7aca76d79388b418"},{"sha":"e8dddcbff72e886f67deebb725ff2cca3e01ec93","author":{"name":"Ionela Voinescu","email":"721bf4aa4c535b5f5f0a38815c215c0ece88733b@arm.com"},"message":"ANDROID: sched/fair: prefer energy efficient CPUs for !prefer_idle tasks\n\nFor !prefer_idle tasks we want to minimize capacity_orig to bias their\nscheduling towards more energy efficient CPUs. This does not happen in\nthe current code for boosted tasks due the order of CPUs considered\n(from big CPUs to LITTLE CPUs), and to the shallow idle state and\nspare capacity maximization filters, which are used to select the best\nidle backup CPU and the best active CPU candidates.\n\nLet's fix this by enabling the above filters only when we are within\nsame capacity CPUs.\n\nTaking in part each of the two cases:\n 1. Selection of a backup idle CPU - Non prefer_idle tasks should prefer\n    more energy efficient CPUs when there are idle CPUs in the system,\n    independent of the order given by the presence of a boosted margin.\n    This is the behavior for !sysctl_sched_cstate_aware and this should\n    be the behaviour for when sysctl_sched_cstate_aware is set as well,\n    given that we should prefer a more efficient CPU even if it's in a\n    deeper idle state.\n\n 2. Selection of an active target CPU: There is no reason for boosted\n    tasks to benefit from a higher chance to be placed on big CPU which\n    is provided by ordering CPUs from bigs to littles.\n    The other mechanism in place set for boosted tasks (making sure we\n    select a CPU that fits the task) is enough for a non latency\n    sensitive case. Also, by choosing a CPU with maximum spare capacity\n    we also cover the preference towards spreading tasks, rather than\n    packing them, which improves the chances for tasks to get better\n    performance due to potential reduced preemption. Therefore, prefer\n    more energy efficient CPUs and only consider spare capacity for CPUs\n    with equal capacity_orig.\n\nChange-Id: I3b97010e682674420015e771f0717192444a63a2\nSigned-off-by: Ionela Voinescu <ionela.voinescu@arm.com>\nSigned-off-by: Patrick Bellasi <patrick.bellasi@arm.com>\nReviewed-by: Patrick Bellasi <patrick.bellasi@arm.com>\nReported-by: Viresh Kumar <viresh.kumar@linaro.org>\nReported-by: Leo Yan <leo.yan@linaro.org>\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/0ctobot/neutrino-staging/commits/e8dddcbff72e886f67deebb725ff2cca3e01ec93"},{"sha":"bb6d80e7efc75c8018c2d9db30bcc71a7c58592c","author":{"name":"Ionela Voinescu","email":"721bf4aa4c535b5f5f0a38815c215c0ece88733b@arm.com"},"message":"ANDROID: sched/fair: unify spare capacity calculation\n\nGiven that we have a few sites where the spare capacity of a CPU is\ncalculated as the difference between the original capacity of the CPU\nand its computed new utilization, let's unify the calculation and use\nthat value tracked with a local spare_cap variable.\n\nChange-Id: I78daece7543f78d4f74edbee5e9ceb62908af507\nSigned-off-by: Ionela Voinescu <ionela.voinescu@arm.com>\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/0ctobot/neutrino-staging/commits/bb6d80e7efc75c8018c2d9db30bcc71a7c58592c"},{"sha":"c5e7f87ac7aa5a06877094e0e9c5fdef1a8e87bf","author":{"name":"Ionela Voinescu","email":"721bf4aa4c535b5f5f0a38815c215c0ece88733b@arm.com"},"message":"ANDROID: sched/fair: remove order from CPU selection\n\nfind_best_target is currently split into code handling latency sensitive\ntasks and code handling non-latency sensitive tasks based on the value\nof the prefer_idle flag.\nAnother differentiation is done for boosted tasks, preferring to start\nwith higher-capacity CPU when boosted, and with more efficient CPUs when\nnot boosted. This additional differentiation is obtained by imposing an\norder when considering CPUs for selection. This order is determined in\ntypical big.LITTLE systems by the start point (the CPU with the maximum\nor minimum capacity) and by the order of big and little CPU groups\nprovided in the sched domain hierarchy.\n\nHowever, it's not guaranteed that the sched domain hierarchy will give\nus a sorted list of CPU groups based on their maximum capacities when\ndealing with systems with more than 2 capacity groups.\nFor example, if we consider a system with three groups of CPUs (LITTLEs,\nmediums, bigs), the sched domain hierarchy might provide the following\nscheduling groups ordering for a prefer_idle-boosted task:\n   big CPUs -> LITTLE CPUs -> medium CPUs.\nIf the big CPUs are not idle, but there are a few LITTLEs and mediums\nas idle CPUs, by returning the first idle CPU, we will be incorrectly\nprefering a lower capacity CPU over a higher capacity CPU.\n\nIn order to eliminate this reliance on assuming sched groups are ordered\nby capacity, let's:\n1. Iterate though all candidate CPUs for all cases.\n2. Minimise or maximise the capacity of the considered CPU, depending\non prefer_idle and boost information.\n\nTaking in part each of the four possible cases we analyse the\nimplementation and impact of this solution:\n\n1. prefer_idle and boosted\nThis type of tasks needs to favour the selection of a reserved idle CPU,\nand thus we still start from the biggest CPU in the system, but we\niterate though all CPUs as to correctly handle the example above by\nmaximising the capacity of the idle CPU we select. When all CPUs are\nactive, we already iterate though all CPUs and we're able to maximise\nspare capacity or minimise utilisation for the considered target or\nbackup CPU.\n\n2. prefer_idle and !boosted\nFor these tasks we prefer the selection of a more energy efficient CPU\nand therefore we start from the smallest CPUs in the system, but we\niterate through all the CPUs as to select the most energy efficient idle\nCPU, implementation which mimics existing behaviour. When all CPUs are\nactive, we already iterate though all CPUs and we're able to\nmaximise spare capacity or minimise utilisation for the considered\ntarget or backup CPU.\n\n3. !prefer_idle and boosted and\n4. !prefer_idle and !boosted\nFor these tasks we already iterate though all CPUs and we're able to\nmaximise the energy efficiency of the selected CPU.\n\nChange-Id: I940399e22eff29453cba0e2ec52a03b17eec12ae\nSigned-off-by: Ionela Voinescu <ionela.voinescu@arm.com>\nSigned-off-by: Patrick Bellasi <patrick.bellasi@arm.com>\nReviewed-by: Patrick Bellasi <patrick.bellasi@arm.com>\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/0ctobot/neutrino-staging/commits/c5e7f87ac7aa5a06877094e0e9c5fdef1a8e87bf"},{"sha":"384ff3948aeed6fc626dcc7140a163f413bf85cc","author":{"name":"Ionela Voinescu","email":"721bf4aa4c535b5f5f0a38815c215c0ece88733b@arm.com"},"message":"ANDROID: sched/fair: add idle state filter to prefer_idle case\n\nThe CPU selection process for a prefer_idle task either minimizes or\nmaximizes the CPU capacity for idle CPUs depending on the task being\nboosted or not.\n\nGiven that we are iterating through all CPUs, additionally filter the\nchoice by preferring a CPU in a more shallow idle state. This will\nprovide both a faster wake-up for the task and higher energy efficiency,\nby allowing CPUs in deeper idle states to remain idle.\n\nChange-Id: Ic55f727a0c551adc0af8e6ee03de6a41337a571b\nSigned-off-by: Ionela Voinescu <ionela.voinescu@arm.com>\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/0ctobot/neutrino-staging/commits/384ff3948aeed6fc626dcc7140a163f413bf85cc"},{"sha":"a96084a0e84bbec5b144467acc9d047f5a99c028","author":{"name":"Ionela Voinescu","email":"721bf4aa4c535b5f5f0a38815c215c0ece88733b@arm.com"},"message":"ANDROID: update_group_capacity for single cpu in cluster\n\nIf we're only left with one big CPU in a cluster (either there was only\none to begin with or the others have been hotplugged out), the MC level\nseen from the perspective of that CPU, will only contain one group (that\nof the CPU) and the LOAD_BALANCE flag will be cleared at that level.\nThe MC level is kept nonetheless as it will still contain energy\ninformation, as per commit 06654998ed81 (\"ANDROID: sched: EAS & 'single\ncpu per cluster'/cpu hotplug interoperability\").\n\nThis will result in update_cpu_capacity never being called for that big\nCPU and its capacity will never be updated. Also, its capacity will\nnever be considered when setting or updating the max_cpu_capacity\nstructure.\n\nTherefore, call update_group_capacity for SD levels that do not have the\nSD_LOAD_BALANCE flag set in order to update the CPU capacity information\nof CPUs that are alone in a cluster and the groups that they belong to.\nThe call to update_cpu_capacity will also result in appropriately\nsetting the values of the max_cpu_capacity structure.\n\nFixes: 06654998ed81 (\"ANDROID: sched: EAS & 'single cpu per cluster'/cpu\nhotplug interoperability\")\nChange-Id: I6074972dde1fdf586378f8a3534e3d0aa42a809a\nSigned-off-by: Ionela Voinescu <ionela.voinescu@arm.com>\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/0ctobot/neutrino-staging/commits/a96084a0e84bbec5b144467acc9d047f5a99c028"},{"sha":"2217c2ea1257c0cfad4ec62c258a35645755129e","author":{"name":"Nathan Chancellor","email":"f65d3f2dc139dcfe7b6f0b0a466af3bc5fed8fa7@gmail.com"},"message":"sched: Update schedtune hold based on the android-4.14 version\n\nThis is the diff between the 4.9 and 4.14 version of the schedtune hold patch.\n\n4.9: https://android-review.googlesource.com/c/kernel/common/+/615807\n\n4.14: https://android.googlesource.com/kernel/common/+/a485e8b7bf8e95759e600396feeb7bfb400b6e46\n\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/0ctobot/neutrino-staging/commits/2217c2ea1257c0cfad4ec62c258a35645755129e"},{"sha":"5c1f09baa8972f17ed035829fe6a24145aba32b1","author":{"name":"Peter Zijlstra","email":"3fddac958924aef220f202ca567388ddab3f14a8@infradead.org"},"message":"BACKPORT: FROMGIT: sched/debug: Explicitly cast sched_feat() to bool\n\nLLVM has a warning that tags expressions like:\n\n\tif (foo && non-bool-const)\n\nThis pattern triggers for CONFIG_SCHED_DEBUG=n where sched_feat() ends\nup being whatever bit we select. Avoid the warning with an explicit\ncast to bool.\n\nReported-by: Philipp Klocke <philipp97kl@gmail.com>\nTested-by: Nick Desaulniers <ndesaulniers@google.com>\nSigned-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: linux-kernel@vger.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n(cherry picked from commit 7e6f4c5d600c1c8e2a1d900e65cab319d9b6782e)\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/0ctobot/neutrino-staging/commits/5c1f09baa8972f17ed035829fe6a24145aba32b1"}]}
{"actor":{"display_login":"0ctobot"}}