Message-ID: <20220527054556.GA2350963@aluminium>
Date:   Fri, 27 May 2022 15:45:56 +1000
From:   Paul Bone <pbone@...illa.com>
To:     Qais Yousef <qais.yousef@....com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Scheduling for heterogeneous computers

On Wed, May 25, 2022 at 04:29:56PM +0100, Qais Yousef wrote:
> 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.

We want to support both desktop and android.  I have been assuming there's
an API for android already, I vaguely remember hearing about it before.  We
might already be using it (at least for processes but not yet for individual
threads).

I was searching online now, but not for very long, and didn't find something
like this, so maybe Android doesn't expose it, or at least not in one of the
APIs they encourage you to use.

What I'd really like is an API where I can choose one of:

 * This task is user-interactive, as-quick-as-possible please.
 * This task is not user-interactive, but does have a deadline.
 * This task doesn't have a deadline.

Rather than choosing a suitable UCLAMP_MAX, I'll expriment with the numbers
but choosing "400" on one system might mean something different from "400"
on another system.  But I guess that's the problem, there are gray areas
between my discrete options above.  A deadline could be "finish doing GC
before we run out of memory" (which can have feedback from the GC about if
it's on target), or "Finish encoding this video before the client wants to
publish it", or "finish rendering this frame of a video game before the next
VBLANK".  Depending on how on-target any of these are we could decrese or
increase clock speed, because decreasing will always save power as long as
things get done by their deadline.

> 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.

Okay thanks.

> 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.

Indeed, servers too.

> 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.

That could be very useful for something on a UI deadline.

> 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 ;-)

Thank you.

Powered by blists - more mailing lists