All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Doug Smythies" <dsmythies@telus.net>
To: "'Zhang, Rui'" <rui.zhang@intel.com>
Cc: <daniel.lezcano@linaro.org>,
	<srinivas.pandruvada@linux.intel.com>, <linux-pm@vger.kernel.org>,
	"'Brown, Len'" <len.brown@intel.com>
Subject: RE: [PATCH] thermal/intel: introduce tcc cooling driver
Date: Mon, 18 Jan 2021 23:10:05 -0800	[thread overview]
Message-ID: <002101d6ee32$1ef449f0$5cdcddd0$@net> (raw)
In-Reply-To: <3942de4204d447228ecb2b8026aa1a51@intel.com>

On 2021.01.18 01:32 Zhang, Rui wrote:
>  On 2021.01.17 05:22 Doug Smythies wrote:
> > On 2021.01.16 09:08 Doug Smythies wrote:
> > > On 2021.01.15 Zhang Rui wrote:
...
> 
> What platform this is?

My i5-9600K test server.
Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz
6 CPUs and 6 cores.
Kernel: 5.11-rc3 + this patch.
Water cooled, with water pump always running full speed.

> On a KBL platform I'm running right now, with performance governor, and tcc offset set to 30
> (Effective TCC  is 70c), and also turbostat fixed,
> I can observe that
> 1. all cpus running at max turbo freq (3.9G) when idle, PkgTmp around 40C
> 2. with load applied (I use stress tool to get 100% CPU load), the PkgTmp reports 70C and the
> frequency drops to  around 3G, IMMEDIATELY.
> 3. when I change TCC Offset to 60, cpu is throttled to around 200MHz, and the temperature is at around
> 50C, IMMEDIATELY.
> 4. when I change TCC Offset to  20, cpu freq raises to turbo range, and PkgTmp reaches 80C,
> IMMEDIATELY.

O.K. You should be able to measure "IMMEDIATELY" and tell us what it is.

> 
> So in your test, there is something I don't understand. 😊
> a) it take such a long time (7+ seconds) to throttle

See test results below, it does seem to throttle quickly, but
then the temperature creeps up.

> b) it throttles to a frequency that is not low enough (in order to keep the system under effective TCC
> temperature, the frequency can be throttled to below turbo range, LFM, and even below LFM in my case)

c) it can take a long time to respond to an increase in allowed temperature. Likely
related to some integral term build up from condition "b" above, because yours isn't clamped
to 3.7 GHz, the response is more "immediate". I test both conditions, repeatedly below.

> 
> Can you please try performance governor and 100% CPU load to see if the symptom is the same?

I did 100% load on 4 of 6 CPUs on purpose: So as not to hit PKG Limit #2 from the outset; To
have 2 CPUs idle, as I thought it might be more challenging.

In terms of maximum heat generation, or maximum energy used, I studied every method I could
find, including several of my own methods, settling on prime95 / torture test / max heat method.

Note: all previous work was done with the intel_pstate driver, HWP enabled, powersave governor.

Test 1: intel_cpufreq,  HWP enabled, performance governor.
Test 1.1: startup delay, requires faster sampling:
MSR_IA32_TEMPERATURE_TARGET: 0x2a64100d (58 C) (100 default - 42 offset)
at 58 degrees it shouldn't clamp.

doug@s18:~$ sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 0.25
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt GFXWatt
0.02    4600    6       31      1.98    0.00
0.53    4600    41      31      2.54    0.00
33.29   4360    645     52      37.34   0.00 <<< PKG Limit #2 already engaged
99.03   4271    1512    59      121.84  0.00 <<< O.K. Seems additional throttling is "IMMEDIATE"
98.85   4244    1511    60      119.81  0.00
98.80   4239    1516    61      119.71  0.00
98.82   4230    1510    63      120.02  0.00
98.84   4228    1509    63      119.32  0.00
98.81   4230    1514    63      120.16  0.00
98.78   4224    1511    63      119.00  0.00
98.82   4226    1510    63      119.18  0.00
98.81   4225    1514    64      119.77  0.00
98.84   4225    1509    63      119.23  0.00
98.82   4225    1511    65      119.56  0.00 <<< But, what? Now 7 degrees over.
   Note: increase in waste heat for otherwise unchanged operating
   conditions is normal at high limits of operation.
   Note: I do not know the level of hysteresis, if any. This might be normal.
98.80   4227    1515    63      119.93  0.00
... delete 14.5 seconds ...
100.25  4217    1514    63      111.25  0.00
100.26  4200    1514    62      109.29  0.00 <<< O.K. finally brings it down.
100.26  4200    1509    62      109.15  0.00
... delete 8.75 seconds
100.26  4100    1509    60      101.64  0.00
100.26  4100    1511    60      101.61  0.00  <<< These two are important, because they
100.25  4010    1515    58      94.65   0.00  <<< reveal that we did not hit PKG Limit #1
                                              <<< 100.0 watts
                                              <<< and we know for certain it is the temp
                                              <<< servo.

Test 1.2: clamp and recover delay, requires slower sampling:

MSR_IA32_TEMPERATURE_TARGET: 0x3f64100d (37 C) (100 default - 63 offset)

$ sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 30
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt GFXWatt
100.26  3700    180608  59      72.80   0.00
100.26  3700    180407  60      72.70   0.00 <<< steady state
100.26  3700    181663  59      72.65   0.00

100.26  3700    46322   59      72.66   0.00 <<< close to time offset set to 37)
100.26  3700    180508  60      72.93   0.00
100.26  3700    180396  59      74.24   0.00
100.26  3700    180330  60      74.74   0.00
100.26  3700    180359  59      74.77   0.00
100.26  3775    180327  64      79.08   0.00 <<< ~~2 minutes 30 seconds response time
100.26  3853    180369  62      84.72   0.00
100.26  3865    180571  64      85.83   0.00
100.26  3866    180383  62      85.90   0.00

Now, change to 1 second sample time and change the offset again,
but this time it is not clamped already first.

doug@s18:~$ sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,GFXWatt,IRQ --interval 1
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt GFXWatt
100.26  3875    6093    62      87.49   0.00 
100.26  3800    6017    62      81.03   0.00 <<< by the way, notice the oscillations
100.26  3883    6023    64      87.98   0.00
100.26  3900    6020    64      89.52   0.00 <<< Processor package power oscillates quite a lot
100.26  3801    6021    62      81.09   0.00 <<< Frequency oscillates also.
100.26  3857    6021    64      85.70   0.00 <<< but in this region, 1 pstate ~= 10 watts
100.26  3900    6018    64      89.34   0.00
...
100.26  3852    6020    62      85.24   0.00
100.26  3800    6019    62      80.82   0.00
100.26  3885    6047    64      87.77   0.00 <<< trip point changed to 70
100.26  3963    6017    67      94.88   0.00 <<< yes, offset change response is fast
100.26  4000    6017    67      98.35   0.00
100.26  4079    6018    69      105.17  0.00
100.26  4100    6017    69      107.02  0.00
... delete 25 seconds ...
100.24  4042    6017    67      102.16  0.00 <<< PKG Limit #1 takes over
100.23  4016    6017    67      99.84   0.00 <<< All throttling is now PKG Limit #1
100.23  4017    6024    68      99.84   0.00
100.23  4015    6026    67      99.77   0.00

Test 2: Test 2: intel_pstate,  HWP enabled, powersave governor.
Test 2.1: startup delay, requires faster sampling:
MSR_IA32_TEMPERATURE_TARGET: 0x2a64100d (58 C) (100 default - 42 offset)
at 58 degrees it shouldn't clamp.

$ sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,IRQ --interval 0.1
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt
0.28    800     12      33      1.93
0.25    800     10      33      1.90
0.31    800     13      33      1.90
0.79    800     19      33      1.92
0.34    800     32      34      1.90
0.22    800     5       33      1.91   <<< ~ 77% of next sample is busy and 20 degrees already
61.91   4103    469     53      60.20  <<< 260 degrees per second
99.01   4264    610     56      121.94 <<< how much PKG Limit #2 and/or TCC loop, I don't know.
98.87   4251    614     61      120.74 <<< unthrottled would be 4.60 GHz
98.87   4235    609     62      119.87
98.85   4226    609     63      119.60
... delete 18.4 seconds
100.26  4100    613     62      102.41
100.26  4100    609     61      102.28
100.25  4040    609     60      97.49  <<< Don't know between PKG Limit #1 and/or TCC loop
100.26  4000    609     59      95.02  <<< definitely TCC loop
100.26  4000    615     60      94.01

Test 2.2: clamp and recover delay, requires slower sampling:

MSR_IA32_TEMPERATURE_TARGET: 0x3f64100d (37 C) (100 default - 63 offset)

sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,IRQ --interval 15
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt
100.26  3700    90167   59      73.97
100.26  3700    90234   58      73.96
100.26  3700    90184   58      74.07

100.26  3700    4073    58      74.09 <<< close to time offset set to 37)
100.26  3700    90222   59      74.12
100.26  3700    90169   59      74.19
100.26  3700    90294   59      73.03
100.26  3700    90164   59      72.63
100.26  3700    90174   59      72.62
100.26  3700    90163   58      72.60
100.26  3700    90208   59      72.58
100.26  3702    90164   60      72.73 <<< 2 minutes until response.
100.26  3831    90169   63      80.67
100.26  3880    90199   63      84.56
100.26  3889    90187   63      85.34
100.26  3900    90170   63      86.24
100.26  3900    90178   62      86.26

Now, change to 0.1 second sample time and change the offset again,
but this time it is not clamped already first.

$ sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,IRQ --interval 0.1
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt
100.26  3900    609     63      89.02
100.26  3900    609     63      89.10

100.26  3900    131     63      89.47  <<< it takes a finite time between here and 
100.26  3900    615     63      89.31  <<< the actual change of offset to 30
... delete 2.7 seconds...              <<< but nowhere near this long.
100.26  3900    614     63      90.08
100.24  3915    609     64      90.42  <<< O.K. responding.
100.26  4000    611     65      98.06
... delete 1.2 seconds ...
100.26  4000    609     65      98.27
100.24  4091    616     67      106.93
100.26  4100    610     68      106.74 <<< Next step.
100.26  4100    609     68      106.90
... delete 4.4 seconds ...
100.26  4100    609     68      108.02
100.24  4107    615     69      107.42 <<< Next step.
100.26  4200    609     70      115.93
100.26  4200    609     71      115.99
100.26  4200    610     71      117.14
100.26  4200    615     70      116.00
100.26  4200    609     70      116.17
100.26  4200    609     70      116.09
100.26  4200    612     71      117.23
100.26  4200    617     70      115.96
100.26  4200    611     70      116.10
100.26  4200    609     70      116.10
100.26  4200    609     70      117.38
100.26  4200    615     70      116.09
100.26  4200    610     70      116.12
100.26  4200    609     70      116.03
100.24  4117    609     69      109.74 <<< O.K. go down again.
100.26  4100    617     69      106.86


Test 3: intel_pstate,  HWP enabled, performance governor.
Test 3.1: startup delay, requires faster sampling:
MSR_IA32_TEMPERATURE_TARGET: 0x2a64100d (58 C) (100 default - 42 offset)
at 58 degrees it shouldn't clamp.

$ sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,IRQ --interval 0.1
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt
0.06    4169    15      32      2.23
0.04    4598    6       33      2.03    <<< ~275 degrees per second
20.09   4599    268     45      15.37   <<< 12 degrees in ~43.7 mSec
99.10   4282    612     55      121.10  <<< how much PKG Limit #2 and/or TCC loop, I don't know.
98.94   4263    610     59      122.18
...delete 17.8 seconds. 63-66 degrees Example:
100.26  4300    609     66      118.93.
...
100.25  4154    610     62      106.06  <<< finally comes down again.
100.26  4100    609     62      101.90
... delete 4.5 seconds
100.26  4100    611     61      102.06
100.26  4100    609     61      102.10
100.25  4038    615     59      98.09   <<< finally gets to temp.
100.26  4000    610     59      93.84   <<< will oscillate here
100.26  4000    609     59      93.88   <<< between pstates 40 and 41
... delete 1.3 seconds ...
100.26  4000    615     58      94.81
100.26  4000    611     59      93.83
100.24  4030    609     60      96.27
100.26  4100    609     60      101.99  
100.26  4100    615     61      102.91
... delete 0.8 seconds ...
100.26  4100    614     61      103.44
100.25  4091    609     61      101.53
100.26  4000    610     59      94.07
...

Test 3.2: clamp and recover delay, requires slower sampling:

MSR_IA32_TEMPERATURE_TARGET: 0x3f64100d (37 C) (100 default - 63 offset)

sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,IRQ --interval 15
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt
100.26  3700    90181   59      74.72
100.26  3700    90383   59      74.75

100.26  3700    2847    59      74.47 <<< close to time offset set to 37)
100.26  3700    90240   59      74.83
100.26  3700    90164   59      74.83
100.26  3700    90225   59      74.85
100.26  3700    90219   59      74.90
100.26  3700    90191   59      74.86
100.26  3700    90166   59      74.86
100.26  3700    90164   59      74.80
100.26  3728    90286   60      76.19 <<< 2 minutes, because it was clamped.
100.26  3832    90162   64      82.67
100.26  3870    90177   63      85.94

Now, change to 0.1 second sample time and change the offset again,
but this time it is not clamped already first.

$ sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,IRQ --interval 0.1
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt
100.26  3900    609     63      88.73
100.26  3900    615     63      88.83

100.26  3900    303     63      89.85 <<< it takes a finite time between here and
100.26  3900    615     63      88.91 <<< the actual change of offset to 30
100.26  3900    610     64      89.64
... delete 2 seconds ...
100.26  3900    611     64      88.75
100.25  3911    609     64      89.58  <<< 1st response
100.26  4000    615     65      97.82
... delete 1.2 seconds ...
100.26  4000    615     66      98.77
100.24  4086    609     68      104.94 <<< next step
100.26  4100    609     67      106.35
...

Test 4: intel_pstate,  HWP enabled, performance governor.
Method of creating 100% CPU load changed to use much less
Energy per thread.
Test 4.1: startup delay, requires faster sampling:
MSR_IA32_TEMPERATURE_TARGET: 0x2a64100d (45 C) (100 default - 55 offset)

Multiple tests were run with 2 through 6 threads.
It took between 6 and 9 seconds to begin to throttle.

Example, 3 threads:
$ sudo ~/turbostat --Summary --quiet --show Busy%,Bzy_MHz,PkgTmp,PkgWatt,IRQ --interval 1
Busy%   Bzy_MHz IRQ     PkgTmp  PkgWatt
0.01    4498    25      32      1.95
0.01    4603    17      32      1.93
0.01    4153    31      31      1.96
36.34   4600    2581    51      35.31 <<< load for last ~ 0.727 seconds.
51.13   4600    3562    52      47.88 
50.77   4600    3620    52      47.98
51.03   4600    3551    52      48.11
51.13   4600    3596    53      48.14
50.87   4600    3627    52      48.20
51.30   4600    3535    52      48.30
51.17   4550    3534    50      46.26 <<< start throttling, ~ 7 seconds
51.27   4452    3567    48      42.05
50.82   4395    3585    47      39.68
51.28   4300    3529    46      36.53 <<< plus another couple to get there.
50.98   4300    3522    47      36.28
51.15   4219    3530    45      34.72
51.08   4200    3678    46      34.33
50.74   4200    3697    46      34.17
51.16   4200    3522    46      34.40
50.99   4126    3534    46      32.44
51.22   4100    3590    44      32.41

... Doug



  reply	other threads:[~2021-01-19  7:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15  9:47 [PATCH] thermal/intel: introduce tcc cooling driver Zhang Rui
2021-01-16 17:08 ` Doug Smythies
2021-01-16 21:21   ` Doug Smythies
2021-01-18  9:31     ` Zhang, Rui
2021-01-19  7:10       ` Doug Smythies [this message]
2021-01-18  9:46   ` Zhang, Rui
2021-01-28 17:32     ` Zhang Rui
2021-01-26 19:18   ` Doug Smythies
2021-01-28 17:29     ` Zhang Rui
2021-01-30 16:58       ` Doug Smythies

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='002101d6ee32$1ef449f0$5cdcddd0$@net' \
    --to=dsmythies@telus.net \
    --cc=daniel.lezcano@linaro.org \
    --cc=len.brown@intel.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=rui.zhang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.