Re: [PATCH] sched/uclamp: Introduce a method to transform UCLAMP_MIN into BOOST

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 23, 2021 at 11:19 PM Dietmar Eggemann
<dietmar.eggemann@xxxxxxx> wrote:
>
> On 21/07/2021 09:57, Xuewen Yan wrote:
> > From: Xuewen Yan <xuewen.yan@xxxxxxxxxx>
> >
> > 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.

Yes, and the patch is indeed used on Android which kernel version is 5.4+.
Because the kernel used in Android do not have the schedtune, and the
uclamp can not
boost all the util, and this is the reason for the design of the patch.

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

YES!

>
> 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`?

Yes, because we do not want to convert completely the uclamp to schedtune,
we also want user can limit some tasks, so the UCLAMP_MAX's meaning
has not been changed,
meanwhile, the UCLAMP_MAX also can affect the margin.

>
> > 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}?

Yes, for per-task, that is no problem, but for per-cgroup, most times,
we can not always only put the special task into the cgroup.
For example, in Android , there is a cgroup named "top-app", often all
the threads of a app would be put into it.
But, not all threads of this app need to be boosted, if we set the
uclamp_min too big, the all the small task would be clamped to
uclamp_min,
the power consumption would be increased, howerever, if setting the
uclamp_min smaller, the performance may be increased.
Such as:
a task's util is 50,  {uclamp_min, uclamp_max} = {100, 1024}
the boost_util =  50 + (100 / 1024) * (1024 - 50) = 145;
but if we set {uclamp_min, uclamp_max} = {280, 1024}, without patch:
the clamp_util = 280.

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

As said above, it is difficult to set the per-cgroup's uclamp_min for
all tasks in Android sometimes.

>
> Uclamp_min is for `boosting`, Uclamp max is for `capping` CPU frequency.

Yes!

>

Thanks!
xuewen




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux