linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Zhang, Rui" <rui.zhang@intel.com>
To: "srinivas.pandruvada@linux.intel.com" 
	<srinivas.pandruvada@linux.intel.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"Neri, Ricardo" <ricardo.neri@intel.com>
Cc: "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"daniel.lezcano@linaro.org" <daniel.lezcano@linaro.org>
Subject: Re: [PATCH v2 0/2] intel_powerclamp: New module parameter
Date: Sun, 5 Feb 2023 15:57:34 +0000	[thread overview]
Message-ID: <a68a6f8c76cb719cd4865bd6aa726306772d4ee3.camel@intel.com> (raw)
In-Reply-To: <20230205025902.2899734-1-srinivas.pandruvada@linux.intel.com>

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

  parent reply	other threads:[~2023-02-05 15:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-05  2:59 [PATCH v2 0/2] intel_powerclamp: New module parameter Srinivas Pandruvada
2023-02-05  2:59 ` [PATCH v2 1/2] Documentation:admin-guide: Move intel_powerclamp documentation Srinivas Pandruvada
2023-02-05  2:59 ` [PATCH v2 2/2] thermal/drivers/intel_powerclamp: Add two module parameters Srinivas Pandruvada
2023-02-05 15:57 ` Zhang, Rui [this message]
2023-02-06  2:45   ` [PATCH v2 0/2] intel_powerclamp: New module parameter srinivas pandruvada
2023-02-06  8:05     ` Zhang, Rui
2023-02-06 10:02       ` srinivas pandruvada
2023-02-07 13:42         ` Ricardo Neri
2023-02-07 13:51           ` srinivas pandruvada
2023-02-07 19:08             ` Ricardo Neri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a68a6f8c76cb719cd4865bd6aa726306772d4ee3.camel@intel.com \
    --to=rui.zhang@intel.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=ricardo.neri@intel.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).