[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d8e14c3c-0eab-2d4d-693e-fb647c7f7c8c@arm.com>
Date: Fri, 23 Jul 2021 17:19:19 +0200
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Xuewen Yan <xuewen.yan94@...il.com>, mingo@...hat.com,
peterz@...radead.org, juri.lelli@...hat.com,
vincent.guittot@...aro.org
Cc: rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
bristot@...hat.com, mcgrof@...nel.org, keescook@...omium.org,
yzaikin@...gle.com, pjt@...gle.com, qais.yousef@....com,
qperret@...gle.com, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] sched/uclamp: Introduce a method to transform UCLAMP_MIN
into BOOST
On 21/07/2021 09:57, Xuewen Yan wrote:
> From: Xuewen Yan <xuewen.yan@...soc.com>
>
> The uclamp can clamp the util within uclamp_min and uclamp_max,
> it is benifit to some tasks with small util, but for those tasks
> with middle util, it is useless.
>
> To speed up those tasks, convert UCLAMP_MIN to BOOST,
> the BOOST as schedtune does:
Maybe it's important to note here that schedtune is the `out-of-tree`
predecessor of uclamp used in some Android versions.
> boot = uclamp_min / SCHED_CAPACITY_SCALE;
> margin = boost * (uclamp_max - util)
> boost_util = util + margin;
This is essentially the functionality from schedtune_margin() in
Android, right?
So in your implementation, the margin (i.e. what is added to the task
util) not only depends on uclamp_min, but also on `uclamp_max`?
> Scenario:
> if the task_util = 200, {uclamp_min, uclamp_max} = {100, 1024}
>
> without patch:
> clamp_util = 200;
>
> with patch:
> clamp_util = 200 + (100 / 1024) * (1024 - 200) = 280;
The same could be achieved by using {uclamp_min, uclamp_max} = {280, 1024}?
Uclamp_min is meant to be the final `boost( = util + margin)`
information. You just have to set it appropriately to the task (via
per-task and/or per-cgroup interface).
Uclamp_min is for `boosting`, Uclamp max is for `capping` CPU frequency.
[...]
Powered by blists - more mailing lists