Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210721075751.542-1-xuewen.yan94@gmail.com> <d8e14c3c-0eab-2d4d-693e-fb647c7f7c8c@arm.com>
 <CAB8ipk9rO7majqxo0eTnPf5Xs-c4iF8TPQqonCjv6sCd2J6ONA@mail.gmail.com> <20210726171716.jow6qfbxx6xr5q3t@e107158-lin.cambridge.arm.com>
In-Reply-To: <20210726171716.jow6qfbxx6xr5q3t@e107158-lin.cambridge.arm.com>
From:   Xuewen Yan <xuewen.yan94@gmail.com>
Date:   Tue, 27 Jul 2021 20:16:25 +0800
Message-ID: <CAB8ipk9cZ4amrarQSN9TtqEwc42RFM1cBUGsTYKuF0maRFx4Zw@mail.gmail.com>
Subject: Re: [PATCH] sched/uclamp: Introduce a method to transform UCLAMP_MIN
 into BOOST
To:     Qais Yousef <qais.yousef@arm.com>
Cc:     Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Juri Lelli <juri.lelli@redhat.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Benjamin Segall <bsegall@google.com>,
        Mel Gorman <mgorman@suse.de>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        mcgrof@kernel.org, Kees Cook <keescook@chromium.org>,
        Iurii Zaikin <yzaikin@google.com>,
        Paul Turner <pjt@google.com>,
        Quentin Perret <qperret@google.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-fsdevel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Qais

On Tue, Jul 27, 2021 at 1:17 AM Qais Yousef <qais.yousef@arm.com> wrote:
>
> > > >
> > > > 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.
>
> It's not really useless, it works as it's designed ;-)

Yes, my expression problem...

>
> As Dietmar highlighted, you need to pick a higher boost value that gives you
> the best perf/watt for your use case.
>
> I assume that this is a patch in your own Android 5.4 kernel, right? I'm not

Yes, the patch indeed is used in my own Android12 with kernel5.4.

> aware of any such patch in Android Common Kernel. If it's there, do you mind
> pointing me to the gerrit change that introduced it?

emmm, sorry I kind of understand what that means.  Your means is  what
I need to do is to send this patch to google?

>
> > 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.
>
> Do you have a specific workload in mind here that is failing? It would help if
> you can explain in detail the mode of failure you're seeing to help us
> understand the problem better.

The patch has has been working with me for a while, I can redo this
data, but this might take a while :)

> >
> > >
> > > > 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;
>
> If a task util was 200, how long does it take for it to reach 280? Why do you
> need to have this immediate boost value applied and can't wait for this time to
> lapse? I'm not sure, but ramping up by 80 points shouldn't take *that* long,
> but don't quote me on this :-)

Here is just one example to illustrate that , with this patch, It also
can boost the util which in {UCLAMP_MIN, UCLAMP_MAX}...

>
> > >
> > > 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.
>
> I assume {uclamp_min, uclamp_max} = {145, 1024} is not good enough because you
> want this 200 task to be boosted to 280. One can argue that not all tasks at
> 200 need to be boosted to 280 too. So the question is, like above, what type
> of tasks that are failing here and how do you observe this failure? It seems
> there's a class of performance critical tasks that need this fast boosting.
> Can't you identify them and boost them individually?

Yes, the best way to do that is boosting them individually, but
usually, it may not be so easy...

>
> There's nothing that prevents you to change the uclamp_min of the cgroup
> dynamically by the way. Like for instance when an app launches you can choose
> a high boost value then lower it once it started up. Or if you know the top-app
> is a game and you want to guarantee a good minimum performance for it; you
> can choose to increase the top-app uclamp_min value too in a special gaming
> mode or something.
>
> For best perf/watt, using the per-task API is the best way forward. But
> I understand it'll take time for apps/android framework to learn how to use the
> per-task API most effectively. But it is what we should be aiming for.

Yes, and I have learned that there is an ADPF framework in Android12,
It can dynamically adjust the per-task's  uclamp_min/max to boost the
task.
Compared to the rough behavior of patch, ADPF may perform better , but
I need to test and compare them...

Thanks!
xuewen.yan