Scheduler utilization clamping

chrisr — Thu, 09 Aug 2018 14:34:28 +0000

I'm not the developer of these patches, but I am familiar with them so I thought I might try to expand a little for readers here who don't use LKML. Utilization clamping doesn't relate to priority or interact with pick_next_task and friends, it is more about the apparent execution time which is tracked (in a frequency and cpu-type invariant manner so that signals can be compared across CPUs in a system) by the scheduler and visible (aggregated at cpu level) to the cpu frequency governors. You cannot change your priority with this API.

This API only allows a task to impose restrictions on itself (i.e. use a lower value for min or max utilization) from the default values, which can be controlled hierarchically using the cpu cgroup controller. Regardless of the presence of this feature or any imposed restrictions on apparent utilization or not, a task may already execute for as long as it has work to do in accordance with it's granted cpu bandwith, priority and scheduling policy. I think the only risk from a malicious application here is running a busy loop to drain a battery or otherwise disrupt system resources - you already have to use the other tools at your disposal to guard against that if you want to, and this feature doesn't change any of those.

The cover letter talks about in future using the restrictions to impact task placement along with frequency guidance but this version only shows frequency guidance as the other mechanisms required to implement the task placement guidance aren't present yet. We've been using SchedTune ( https://lwn.net/Articles/706374/ ) in Android for equivalent functionality for a few years now but it wasn't really suitable for all Linux kernel users hence the util-clamp patches. In SchedTune we already use the modified utilization signals to limit the potential pool of CPUs in big.LITTLE systems (i.e. you can configure a task to never look large enough to run on a big CPU or never look small enough to run on a little CPU) but you can't do that without the scheduler making use of task utilization when selecting candidate CPUs for placement which isn't present upstream yet. The Energy Aware Scheduling patches - which Jonathan wrote about at https://lwn.net/Articles/749900/ - add utilization & capacity aware wakeup placement to CFS and v5 can be seen at https://lore.kernel.org/lkml/20180724122521.22109-1-quent... if anyone wants to test/review it. Once such mechanisms are available to the scheduler, they can be extended to use the utilization-clamped values to influence task placement as well.

Another part of the solution for improving task placement in a big.LITTLE system that we use in Android is made from a feature called 'Misfit Task Detection', which you can also find on LKML at https://lore.kernel.org/lkml/1530699470-29808-1-git-send-...

These pieces are individually useful but also fit together to provide all the mechanisms required for fine-grained control of CPU placement and frequency selection to an intelligent userspace for battery powered devices and potentially other types of hardware.

Mischevious processes

daurnimator — Thu, 09 Aug 2018 12:42:34 +0000

How would it have any effect worse than entering a busyloop?

Mischevious processes

gshrikant — Thu, 09 Aug 2018 03:30:22 +0000

I'm pretty sure this has already been considered but if processes don't need special privileges decide their minimum clamp value - which affect how frequently it gets chosen - wouldn't this lead to mischievous processes abusing this feature to prioritize themselves?

LWN: Comments on "Scheduler utilization clamping"

Scheduler utilization clamping

Mischevious processes

Mischevious processes