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;
Message-ID: <044424e924967a1c93649812b6e1670c8c37fce4.camel@intel.com>
Subject: Re: [RFC PATCH v4 0/2] cpuidle: teo: Introduce util-awareness
From:   Zhang Rui <rui.zhang@intel.com>
To:     Doug Smythies <dsmythies@telus.net>,
        'Kajetan Puchalski' <kajetan.puchalski@arm.com>,
        rafael@kernel.org
Cc:     daniel.lezcano@linaro.org, lukasz.luba@arm.com,
        Dietmar.Eggemann@arm.com, yu.chen.surf@gmail.com,
        linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Date:   Sun, 27 Nov 2022 00:26:09 +0800
In-Reply-To: <00a801d8ffba$6cd72a70$46857f50$@telus.net>
References: <20221102152808.2978590-1-kajetan.puchalski@arm.com>
         <Y3ttlCCezC+SvFDH@e126311.manchester.arm.com>
         <00a801d8ffba$6cd72a70$46857f50$@telus.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5-0ubuntu1 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 2022-11-23 at 20:08 -0800, Doug Smythies wrote:
> On 2022.11.21 04:23 Kajetan Puchalski wrote:
> 
> > Hi Rafael,
> > 
> > On Wed, Nov 02, 2022 at 03:28:06PM +0000, Kajetan Puchalski wrote:
> > 
> > [...]
> > 
> > > v3 -> v4:
> > > - remove the chunk of code skipping metrics updates when the CPU
> > > was utilized
> > > - include new test results and more benchmarks in the cover
> > > letter
> > 
> > [...]
> > 
> > It's been some time so I just wanted to bump this, what do you
> > think
> > about this v4? Doug has already tested it, resuls for his machine
> > are
> > attached to the v3 thread.
> 
> Hi All,
> 
> I continued to test this and included the proposed ladder idle
> governor in my continued testing.
> (Which is why I added Rui as an addressee)

Hi, Doug,

Really appreciated your testing data on this.
I have some dumb questions and I need your help so that I can better
understand some of the graphs. :)

> However, I ran out of time. Here is what I have:
> 
> Kernel: 6.1-rc3 and with patch sets
> Processor: Intel(R) Core(TM) i5-10600K CPU @ 4.10GHz
> CPU scaling driver: intel_cpufreq
> HWP disabled.
> Unless otherwsie stated, performance CPU scaling govenor.
> 
> Legend:
> teo: the current teo idle governor
> util-v4: the RFC utilization teo patch set version 4.
> menu: the menu idle governor
> ladder-old: the current ladder idle governor
> ladder: the RFC ladder patchset.
> 
> Workflow: shell-intensive serialized workloads.
> Variable: PIDs per second.
> Note: Single threaded.
> Master reference: forced CPU affinity to 1 CPU.
> Performance Results:
> http://smythies.com/~doug/linux/idle/teo-util/graphs/pids-perf.png
> Schedutil Results:
> http://smythies.com/~doug/linux/idle/teo-util/graphs/pids-su.png

what does 1cpu mean?

> 
> Workflow: sleeping ebizzy 128 threads.
> Variable: interval (uSecs).
> Performance Results:
> http://smythies.com/~doug/linux/idle/teo-util/graphs/ebizzy-128-perf.png
> Performance power and idle data:
> http://smythies.com/~doug/linux/idle/teo-util/ebizzy/perf/

for the "Idle state 0/1/2/3 was too deep" graphs, may I know how you
assert that an idle state is too deep/shallow?

thanks,
rui