linux-kernel - Re: [PATCH v2 0/2] intel_powerclamp: New module parameter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 5 Feb 2023 15:57:34 +0000
From:   "Zhang, Rui" <rui.zhang@...el.com>
To:     "srinivas.pandruvada@...ux.intel.com" 
        <srinivas.pandruvada@...ux.intel.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "Neri, Ricardo" <ricardo.neri@...el.com>
CC:     "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>
Subject: Re: [PATCH v2 0/2] intel_powerclamp: New module parameter

Hi, Srinivas,

First of all, the previous build error is gone.

Second, I found something strange, which may be related with the
scheduler asym-packing, so CC Ricardo.

The test is done with pm linux-intel branch + this patch series on an
ADL system. cpu0~cpu7 are Pcore cpus, cpu8-cpu15 are Ecore cpus, and
intel_powerclamp is register as cooling_device21.

1. run stress -c 16
2. update /sys/module/intel_powerclamp/parameters/cpumask
   echo 90 > /sys/module/intel_powerclamp/parameters/max_idle
3. echo 90 > /sys/class/thermal/cooling_device21/cur_state
4. echo 0 > /sys/class/thermal/cooling_device21/cur_state
I use turbostat to monitor the CPU Busy% in all 4 steps.

If 'cpumask' does not include all the Ecore CPUs, all CPUs becomes 100%
busy after idle injection removed in step 4.

If 'cpumask' includes all the Ecore CPUs, i.e. cpumask = FFxy, in some
cases, the Ecore CPUs will drop to an Busy% much lower than 10%, and
then they don't come back to busy after idle injection removed in step
4, although we have 16 stress threads. And this also relates with how
long we stay in idle injection.

Say, when cpumask=fff3, the problem can be triggered occasionally if
there is a 10 second timeout between step 3 and step4, but it is much
easier to reproducible if I increase the timeout to 20 seconds.

It seems that Pcore can always pull tasks from Ecores, but Ecore can
not pull tasks from Pcore HT siblings.

thanks,
rui

On Sat, 2023-02-04 at 18:59 -0800, Srinivas Pandruvada wrote:
> Split from the series for powerclamp user of powercap idle-inject.
> 
> v2
> - Build warnings reported by Rui
> - Moved the powerclamp documentation to admin guide folder
> - Commit log updated as suggested by Rafael and other code suggestion
> 
> Srinivas Pandruvada (2):
>   Documentation:admin-guide: Move intel_powerclamp documentation
>   thermal/drivers/intel_powerclamp: Add two module parameters
> 
>  Documentation/admin-guide/index.rst           |   1 +
>  .../thermal/intel_powerclamp.rst              |  22 +++
>  Documentation/driver-api/thermal/index.rst    |   1 -
>  MAINTAINERS                                   |   1 +
>  drivers/thermal/intel/intel_powerclamp.c      | 177 +++++++++++++++-
> --
>  5 files changed, 180 insertions(+), 22 deletions(-)
>  rename Documentation/{driver-api => admin-
> guide}/thermal/intel_powerclamp.rst (93%)
>