Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [RFC v3 0/5] Add capacity capping support to the CPU controller | Date | Wed, 15 Mar 2017 12:41:54 +0100 |
| |
On Tuesday, February 28, 2017 02:38:37 PM Patrick Bellasi wrote: > Was: SchedTune: central, scheduler-driven, power-perfomance control > > This series presents a possible alternative design for what has been presented > in the past as SchedTune. This redesign has been defined to address the main > concerns and comments collected in the LKML discussion [1] as well at the last > LPC [2]. > The aim of this posting is to present a working prototype which implements > what has been discussed [2] with people like PeterZ, PaulT and TejunH. > > The main differences with respect to the previous proposal [1] are: > 1. Task boosting/capping is now implemented as an extension on top of > the existing CGroup CPU controller. > 2. The previous boosting strategy, based on the inflation of the CPU's > utilization, has been now replaced by a more simple yet effective set > of capacity constraints. > > The proposed approach allows to constrain the minimum and maximum capacity > of a CPU depending on the set of tasks currently RUNNABLE on that CPU. > The set of active constraints are tracked by the core scheduler, thus they > apply across all the scheduling classes. The value of the constraints are > used to clamp the CPU utilization when the schedutil CPUFreq's governor > selects a frequency for that CPU. > > This means that the new proposed approach allows to extend the concept of > tasks classification to frequencies selection, thus allowing informed > run-times (e.g. Android, ChromeOS, etc.) to efficiently implement different > optimization policies such as: > a) Boosting of important tasks, by enforcing a minimum capacity in the > CPUs where they are enqueued for execution. > b) Capping of background tasks, by enforcing a maximum capacity. > c) Containment of OPPs for RT tasks which cannot easily be switched to > the usage of the DL class, but still don't need to run at the maximum > frequency.
Do you have any practical examples of that, like for example what exactly Android is going to use this for?
I gather that there is some experience with the current EAS implementation there, so I wonder how this work is related to that.
Thanks, Rafael
| |