Re: [RFC PATCH v1] sched/uclamp: Introduce SCHED_FLAG_RESET_UCLAMP_ON_FORK flag

[David Dai]

On Tue, Apr 18, 2023 at 10:18 PM Dietmar Eggemann
<dietmar.eggemann@xxxxxxx> wrote:
>

Hi Dietmar, thanks for your time,

> On 16/04/2023 23:34, David Dai wrote:
> > A userspace service may manage uclamp dynamically for individual tasks and
> > a child task will unintentionally inherit a pesudo-random uclamp setting.
> > This could result in the child task being stuck with a static uclamp value
>
> Could you explain this with a little bit more detail? Why isn't the
> child task also managed by the userspace service?

See Qais’ reply that contains more detail on how it’s being used in
Android. In general, if a dynamic userspace service will adjust uclamp
on the fly for a given task, but has no knowledge or control over if
or when a task forks. Depending on the timing of the fork, a child
task may inherit a very large or a small uclamp_min or uclamp_max
value. The intent of this patch is to provide more flexibility to the
uclamp APIs such that child tasks do not get stuck with a poor uclamp
value when spawned while retaining other sched attributes. When
RESET_ON_FORK is set on the parent task, it will reset uclamp values
for the child but also reset other sched attributes as well.

>
> The child task will only make a difference if it's on the rq.
>
> Does this issue happen with uclamp mainline or only with Android's
> slightly different version (max- vs. sum aggregation)?

I’m using the version of uclamp that’s in Linus’ tree. How uclamp is
aggregated is unrelated to the problem I’m trying to solve with this
patch. Which is to extend the uclamp APIs to have finer control for
the uclamp inheritance of child tasks.

Thanks,
David

>
> > that results in poor performance or poor power.
> >
> > Using SCHED_FLAG_RESET_ON_FORK is too coarse for this usecase and will
> > reset other useful scheduler attributes. Adding a
> > SCHED_FLAG_RESET_UCLAMP_ON_FORK will allow userspace to have finer control
> > over scheduler attributes of child processes.
>
> [...]
>