Messages in this thread | | | Date | Wed, 25 May 2022 16:29:56 +0100 | From | Qais Yousef <> | Subject | Re: Scheduling for heterogeneous computers |
| |
Hi Paul
On 05/24/22 15:23, Paul Bone wrote: > Hi Qais, > > That's excellent. > > I'll definitely check out those links. This could be very interesting for > people using firefox on a phone/tablet, where we can run background tasks with > a lower UCLAMP_MAX
If you're running on Android, you might find that you won't have permission to use uclamp directly. Android restricts access and requires you to use higher level APIs sometimes.
And I'm not sure if they have API to allow you to do what you want. I've seen they have the concept of creating Foreground and Background jobs in one of their Google IO presentations. But not sure if this will be tied to uclamp_max. It might give you similar results still though regardless of the underlying mechanism.
If you're running on mainline kernel, then the biggest issue you might encounter is that sched_setattr() syscall is not part of any libc yet. So you need to create your own wrapper - look at uclampset for an example.
Laptops can still benefit from this by the way. Hopefully everyone is moving to schedutil by default which is a pre-requisite to using uclamp. It can also help in SMP environments to avoid driving frequency high for tasks that don't really care about performance but otherwise busy.
You can also use UCLAMP_MIN to boost bursty tasks that are not busy but require to get work done within a certain amount of time and DVFS delays can prevent them from running at adequate frequency. UCLAMP_MIN will ensure they always perceive a performance point specified by UCLAMP_MIN at a minimum when they wakeup.
RT tasks respect uclamp values too. You can opt-in to run at a different frequency than MAX frequency which leads to high power consumption on battery powered devices. RT tasks always run at constant frequency, so need to be controlled with UCLAMP_MIN only.
Happy hacking ;-)
Cheers
-- Qais Yousef
| |