{"push_id":3166725164,"size":3,"distinct_size":3,"ref":"refs/heads/9.0","head":"29119e6948f198cc3cc1d9f7667837c2b39222bb","before":"7a04d43def93cae55863794d7277eb215723eaae","commits":[{"sha":"7c40af6bfeac06b41996985b05ec6d6ebd2e054d","author":{"name":"Pavankumar Kondeti","email":"e4a0348e45a0df0ba79f6b06c66df8ae7aca44a4@codeaurora.org"},"message":"ANDROID: sched/fair: fix CPU selection for non latency sensitive tasks\n\nThe Non latency sensitive tasks CPU selection targets for an active\nCPU in the little cluster. The shallowest c-state CPU is stored as\na backup. However if all CPUs in the little cluster are idle, we pick\nan active CPU in the BIG cluster as the target CPU. This incorrect\nchoice of the target CPU may not get corrected by the\nselect_energy_cpu_idx() depending on the energy difference between\nprevious CPU and target CPU.\n\nThis can be fixed easily by maintaining the same variable that tracks\nmaximum capacity of the traversed CPU for both idle and active CPUs.\n\nChange-Id: I3efb8bc82ff005383163921ef2bd39fcac4589ad\nSigned-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>\nSigned-off-by: Nathan Chancellor <natechancellor@gmail.com>","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/7c40af6bfeac06b41996985b05ec6d6ebd2e054d"},{"sha":"102485b797f9246816a10a322f8b7ccd1b18f0ef","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/whoknowswhoiam/weebmsm8998-pie/commits/102485b797f9246816a10a322f8b7ccd1b18f0ef"},{"sha":"29119e6948f198cc3cc1d9f7667837c2b39222bb","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/whoknowswhoiam/weebmsm8998-pie/commits/29119e6948f198cc3cc1d9f7667837c2b39222bb"}]}
{"actor":{"display_login":"whoknowswhoiam"}}