Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220915164411.2496380-1-kajetan.puchalski@arm.com> <20220915164411.2496380-2-kajetan.puchalski@arm.com>
In-Reply-To: <20220915164411.2496380-2-kajetan.puchalski@arm.com>
From:   Chen Yu <yu.chen.surf@gmail.com>
Date:   Sun, 18 Sep 2022 15:17:02 +0800
Message-ID: <CADjb_WR9=p=9nX9oJLv5ZCrrSaHt58Yh22K2=S9E71fSdr0+KA@mail.gmail.com>
Subject: Re: [RFC PATCH 1/1] cpuidle: teo: Add optional util-awareness
To:     Kajetan Puchalski <kajetan.puchalski@arm.com>
Cc:     rafael@kernel.org, daniel.lezcano@linaro.org, lukasz.luba@arm.com,
        Dietmar.Eggemann@arm.com, linux-pm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Chen Yu <yu.c.chen@intel.com>,
        Zhang Rui <rui.zhang@intel.com>,
        Len Brown <len.brown@intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Sep 16, 2022 at 12:49 AM Kajetan Puchalski
<kajetan.puchalski@arm.com> wrote:
>
> Modern interactive systems, such as recent Android phones, tend to have
> power efficient shallow idle states. Selecting deeper idle states on a
> device while a latency-sensitive workload is running can adversely impact
> performance due to increased latency. Additionally, if the CPU wakes up
> from a deeper sleep before its target residency as is often the case, it
> results in a waste of energy on top of that.
>
> This patch extends the TEO governor with an optional mechanism adding
> util-awareness, effectively providing a way for the governor to switch
> between only selecting the shallowest idle state when the cpu is being
> utilized over a certain threshold and trying to select the deepest possible
> state using TEO's metrics when the cpu is not being utilized.
Not sure if we can use util_avg as schedutil, but it looks interesting.
The last time I was trying to propose an idea to leverage util_avg to
optimize some
codes in the kernel, it was suggested that it would be better to make
the stategy
gradual rather than 0,1 state. So I was thinking if we could make it
something like:

next_idx = cpuidle_select();
next_idx = next_idx * (cpu_cap - util_avg) / cpu_cap;

The lower the util_avg is, the more we honor the choice of the governor,
vice versa.
> This is now possible since the CPU utilization is exported from the scheduler with the
> sched_cpu_util function and already used e.g. in the thermal governor IPA.
>
> This can provide drastically decreased latency and performance benefits in
> certain types of mobile workloads that are sensitive to latency,
> such as Geekbench 5.
As Doug mentioned in another thread, the impact data to energy consumption would
also be interesting.

thanks,
Chenyu