Re: [PATCH v2 09/13] sched/qos: Add rampup multiplier QoS

[Peter Zijlstra]

On Mon, May 04, 2026 at 02:59:59AM +0100, Qais Yousef wrote:

> diff --git a/Documentation/scheduler/sched-qos.rst b/Documentation/scheduler/sched-qos.rst
> index 0911261cb124..f68856f23b6b 100644
> --- a/Documentation/scheduler/sched-qos.rst
> +++ b/Documentation/scheduler/sched-qos.rst
> @@ -42,3 +42,25 @@ need for extension will arise; and when this happen the task should be
>  simpler to add the kernel extension and allow userspace to use readily by
>  setting the newly added flag without having to update the whole of
>  sched_attr.
> +
> +2. QoS Tags
> +===========
> +
> +SCHED_QOS_RAMPUP_MULTIPLIER
> +---------------------------
> +
> +Controls how fast util signal rises. Affects frequency selection when schedutil
> +is in use. And affects how fast tasks migrate between clusters on HMP systems.
> +
> +It affects bursty tasks only. Perfectly periodic tasks are well described by
> +util_avg and the rampup multiplier will have no effect on them.
> +
> +When set to 0, util_est will be disabled to help further with power saving.
> +This behavior can be controlled via UTIL_EST_RAMPUP_ZERO sched_feature.
> +
> +Value is not capped to retain flexibility, but it tapers off very quickly to
> +notice a difference above 16. Roughly it takes ~200ms to reach a util_avg of
> +1000 starting from 0. With 16 it should take ~12.5ms. A range of 0-8 is
> +advised for general use.
> +
> +Cookie must always be set to 0.

So this is a very specific feature. This is made possible by basically
having a huge type space, allowing for throw-away hints (as per the
previous email).

I suppose having these specific hints is easy, but as per always there
is the discussion about describing task behaviour vs implementation
details. With the argument being that task behaviour might be a more
lasting / stable hint, while implementation details are far easier to
actually do.

I'm missing this discussion.