On 09/10/2019 19:02, Parth Shah wrote: > > > On 10/9/19 7:56 PM, Dietmar Eggemann wrote: >> On 09/10/2019 10:57, Parth Shah wrote: >> >> [...] >> >>>> On 07/10/2019 18:53, Parth Shah wrote: >>>>> >>>>> >>>>> On 10/7/19 5:49 PM, Vincent Guittot wrote: >>>>>> On Mon, 7 Oct 2019 at 10:31, Parth Shah <pa...@linux.ibm.com> wrote:
[...] > ok. so does that mean TurboSched can still do some good in such systems as > well ? > I mean save energy even when rd->overutilized==1 by not waking user > classified bg tasks on idle core. I wouldn't say it is impossible but how likely would it be? The Android runtime already classifies its tasks into groups such as background, foreground, top-app, etc. It uses existing infrastructure like cpusets, taskgroups, util_clamp (or its out-of-tree predecessor schedtune) as well as EAS/Energy Model on asymmetric CPU capacity systems to map them (differently) onto the CPU topology to achieve the best possible performance/energy consumption trade-off. Moreover, Google and Arm are keen getting the concept of 'latency nice' upstream so we can map Android Common Kernel's 'prefer idle' feature into the mainline energy-aware wu path. So I'm afraid the question whether TurboSched could make sense on an Android system can only be answered by people responsible for future Android runtime architecture.
