Groups > linux.kernel > #1366506 > unrolled thread

Re: [intel-pstate driver regression] processor frequency very high even if in idle

Started by	Jörg Otte <jrg.otte@gmail.com>
First post	2016-03-29 19:40 +0200
Last post	2016-03-30 21:00 +0200
Articles	20 on this page of 40 — 6 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

  Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-03-29 19:40 +0200
    Re: [intel-pstate driver regression] processor frequency very high even if in idle "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-29 23:40 +0200
      Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-03-30 12:20 +0200
        Re: [intel-pstate driver regression] processor frequency very high  even if in idle "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-30 13:10 +0200
          Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-03-30 17:30 +0200
            Re: [intel-pstate driver regression] processor frequency very high even if in idle "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-30 20:40 +0200
              Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-03-31 11:10 +0200
                Re: [intel-pstate driver regression] processor frequency very high even if in idle "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-31 13:50 +0200
                  Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-03-31 17:30 +0200
                    Re: [intel-pstate driver regression] processor frequency very high even if in idle "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-03-31 17:50 +0200
                      Re: [intel-pstate driver regression] processor frequency very high  even if in idle Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-03-31 18:20 +0200
                      Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-03-31 19:30 +0200
                        Re: [intel-pstate driver regression] processor frequency very high  even if in idle Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-03-31 20:00 +0200
                          Re: [intel-pstate driver regression] processor frequency very high  even if in idle "Rafael J. Wysocki" <rafael@kernel.org> - 2016-04-01 02:10 +0200
                          Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-04-01 11:50 +0200
                            Re: [intel-pstate driver regression] processor frequency very high  even if in idle Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-04-01 17:10 +0200
                              Re: [intel-pstate driver regression] processor frequency very high  even if in idle "Rafael J. Wysocki" <rafael@kernel.org> - 2016-04-01 22:30 +0200
                      Re: [intel-pstate driver regression] processor frequency very high even if in idle "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-04-01 14:40 +0200
                        Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-04-01 16:10 +0200
                          Re: [intel-pstate driver regression] processor frequency very high  even if in idle Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-04-01 19:50 +0200
                            RE: [intel-pstate driver regression] processor frequency very high even if in idle "Doug Smythies" <dsmythies@telus.net> - 2016-04-01 20:40 +0200
                              Re: [intel-pstate driver regression] processor frequency very high  even if in idle Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-04-01 20:50 +0200
                              Re: [intel-pstate driver regression] processor frequency very high  even if in idle "Rafael J. Wysocki" <rafael@kernel.org> - 2016-04-01 22:00 +0200
                                RE: [intel-pstate driver regression] processor frequency very high even if in idle "Doug Smythies" <dsmythies@telus.net> - 2016-04-02 01:40 +0200
                                  Re: [intel-pstate driver regression] processor frequency very high  even if in idle "Rafael J. Wysocki" <rafael@kernel.org> - 2016-04-02 02:30 +0200
                          Re: [intel-pstate driver regression] processor frequency very high  even if in idle "Rafael J. Wysocki" <rafael@kernel.org> - 2016-04-01 22:30 +0200
                        RE: [intel-pstate driver regression] processor frequency very high even if in idle "Doug Smythies" <dsmythies@telus.net> - 2016-04-01 17:30 +0200
                          Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-04-01 18:50 +0200
                            Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-04-01 19:40 +0200
          Re: [intel-pstate driver regression] processor frequency very high  even if in idle "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com> - 2016-03-30 17:40 +0200
            Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-03-30 18:00 +0200
              Re: [intel-pstate driver regression] processor frequency very high  even if in idle Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-03-30 21:00 +0200
                Re: [intel-pstate driver regression] processor frequency very high  even if in idle "Rafael J. Wysocki" <rafael@kernel.org> - 2016-03-30 22:20 +0200
                  Re: [intel-pstate driver regression] processor frequency very high  even if in idle Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-03-30 22:30 +0200
                    Re: [intel-pstate driver regression] processor frequency very high  even if in idle Jörg Otte <jrg.otte@gmail.com> - 2016-03-31 11:30 +0200
                      RE: [intel-pstate driver regression] processor frequency very high even if in idle "Doug Smythies" <dsmythies@telus.net> - 2016-03-31 16:40 +0200
                        RE: [intel-pstate driver regression] processor frequency very high even if in idle "Doug Smythies" <dsmythies@telus.net> - 2016-03-31 17:20 +0200
                        Re: [intel-pstate driver regression] processor frequency very high  even if in idle Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> - 2016-03-31 17:20 +0200
                      RE: [intel-pstate driver regression] processor frequency very high even if in idle "Doug Smythies" <dsmythies@telus.net> - 2016-04-01 09:30 +0200
              RE: [intel-pstate driver regression] processor frequency very high even if in idle "Doug Smythies" <dsmythies@telus.net> - 2016-03-30 21:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1369517 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

From	"Doug Smythies" <dsmythies@telus.net>
Date	2016-04-01 20:40 +0200
Subject	RE: [intel-pstate driver regression] processor frequency very high even if in idle
Message-ID	<rjc9c-8p1-21@gated-at.bofh.it>
In reply to	#1369501

On 2106.034.01 10:45 Srinivas Pandruvada wrote:
> On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote:
> > > > > > 
>> Done. Attached the tracer.
>> For me it looks like the previous one of the failing case.
> 
> The traces show that idle task is constantly running without sleep.

No, they (at least the first one, I didn't look at the next one yet)
show that CPUs 2 and 3 are spending around 99% of their time not in state
C0. That the sample rate is ending up at ~10 Milliseconds, indicates some
high frequency (>= 100Hz) events on those CPUs. Those events, apparently,
take very little CPU time to complete, hence a load of about 1% on average.

By the way, I can recreate the high sample rate with virtually no load
on my system easy, but so far have been unable to get the high CPU
frequencies observed by Jörg. I can get my system to about a target pstate of
20 where it should have remained at 16, but that is about it.

> The driver is processing samples for idle task for every 10ms and
> aperf/mperf are showing that we are always in turbo mode for idle task.

That column pretty much always says "idle" (or swapper for my way of doing
things). I have not found it to very useful as an indicator, and considerably
more so since the utilization changes.

> 
> Need to find out why idle task is not sleeping.

I contend that is it.
I don't have enough reverted data, but so far this seems very much like
that bug report I referenced earlier.

... Doug

[toc] | [prev] | [next] | [standalone]

#1369524

From	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date	2016-04-01 20:50 +0200
Message-ID	<rjciR-8u7-11@gated-at.bofh.it>
In reply to	#1369517

On Fri, 2016-04-01 at 11:31 -0700, Doug Smythies wrote:
> On 2106.034.01 10:45 Srinivas Pandruvada wrote:
> > 
> > On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote:
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > Done. Attached the tracer.
> > > For me it looks like the previous one of the failing case.
> > The traces show that idle task is constantly running without sleep.
> No,
I mean atleast on once CPU. I am not saying they are looping, but the
wakeup time is less than 10ms, so the driver will not scale the load
for idle time.

>  they (at least the first one, I didn't look at the next one yet)
> show that CPUs 2 and 3 are spending around 99% of their time not in
> state
> C0. That the sample rate is ending up at ~10 Milliseconds, indicates
> some
> high frequency (>= 100Hz) events on those CPUs. Those events,
> apparently,
> take very little CPU time to complete, hence a load of about 1% on
> average.
> 
> By the way, I can recreate the high sample rate with virtually no
> load
> on my system easy, but so far have been unable to get the high CPU
> frequencies observed by Jörg. I can get my system to about a target
> pstate of
> 20 where it should have remained at 16, but that is about it.
> 
> > 
> > The driver is processing samples for idle task for every 10ms and
> > aperf/mperf are showing that we are always in turbo mode for idle
> > task.
> That column pretty much always says "idle" (or swapper for my way of
> doing
> things). I have not found it to very useful as an indicator, and
> considerably
> more so since the utilization changes.
> 
> > 
> > 
> > Need to find out why idle task is not sleeping.
> I contend that is it.
> I don't have enough reverted data, but so far this seems very much
> like
> that bug report I referenced earlier.
> 
> ... Doug
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1369565

From	"Rafael J. Wysocki" <rafael@kernel.org>
Date	2016-04-01 22:00 +0200
Message-ID	<rjdoD-Hb-37@gated-at.bofh.it>
In reply to	#1369517

On Fri, Apr 1, 2016 at 8:31 PM, Doug Smythies <dsmythies@telus.net> wrote:
> On 2106.034.01 10:45 Srinivas Pandruvada wrote:
>> On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote:
>> > > > > >
>>> Done. Attached the tracer.
>>> For me it looks like the previous one of the failing case.
>>
>> The traces show that idle task is constantly running without sleep.
>
> No, they (at least the first one, I didn't look at the next one yet)
> show that CPUs 2 and 3 are spending around 99% of their time not in state
> C0.

How do you figure that out if I may ask?  It is not so obvious to me
to be honest.

> That the sample rate is ending up at ~10 Milliseconds, indicates some
> high frequency (>= 100Hz) events on those CPUs. Those events, apparently,
> take very little CPU time to complete, hence a load of about 1% on average.
>
> By the way, I can recreate the high sample rate with virtually no load
> on my system easy, but so far have been unable to get the high CPU
> frequencies observed by Jörg. I can get my system to about a target pstate of
> 20 where it should have remained at 16, but that is about it.
>
>> The driver is processing samples for idle task for every 10ms and
>> aperf/mperf are showing that we are always in turbo mode for idle task.
>
> That column pretty much always says "idle" (or swapper for my way of doing
> things). I have not found it to very useful as an indicator, and considerably
> more so since the utilization changes.
>
>>
>> Need to find out why idle task is not sleeping.
>
> I contend that is it.

Why?

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1369660 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

From	"Doug Smythies" <dsmythies@telus.net>
Date	2016-04-02 01:40 +0200
Subject	RE: [intel-pstate driver regression] processor frequency very high even if in idle
Message-ID	<rjgPv-3e4-3@gated-at.bofh.it>
In reply to	#1369565

On 2016.04.01 12:54 Rafael J. Wysocki wrote:
>On Fri, Apr 1, 2016 at 8:31 PM, Doug Smythies <dsmythies@telus.net> wrote:
>> On 2106.034.01 10:45 Srinivas Pandruvada wrote:
>>> On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote:
>> > > > > >
>>>> Done. Attached the tracer.
>>>> For me it looks like the previous one of the failing case.
>>>
>>> The traces show that idle task is constantly running without sleep.
>>
>> No, they (at least the first one, I didn't look at the next one yet)
>> show that CPUs 2 and 3 are spending around 99% of their time not in state
>> C0.

> How do you figure that out if I may ask?  It is not so obvious to me
> to be honest.

The trace was not in the form for the post processing tools, so I had
to manually import the trace into a spreadsheet and manually add new columns
calculated from the others.

Load = mperf / tsc * 100 % = C0 time.
Duration (mS) = tsc / 2.5e9 * 1000 
Note: I do not recall seeing an exact tsc for Jörg's computer, so I used
The 2.5 GHz from the device spec from some earlier e-mail.

Example (formatting will likely not send O.K.):

		CPU#	time		core_busy	scaled	from	to	mperf		aperf		tsc		freq		load		duration (ms)
<idle>-0	[002]	465.879451:	100		96		26	26	1826656	1826710	25062693	2500073	7.288%	10.025
<idle>-0	[003]	465.879484:	99		96		26	26	305796	305781	25147993	2499877	1.216%	10.059
<idle>-0	[000]	465.885794:	100		96		26	26	975908	975951	32434672	2500110	3.009%	12.974
<idle>-0	[001]	465.886898:	100		250		10	31	327356	327364	26673840	2500061	1.227%	10.670
<idle>-0	[002]	465.889527:	100		96		26	26	205336	205365	25133396	2500353	0.817%	10.053
<idle>-0	[003]	465.889555:	99		95		26	26	62544		62341		25117916	2491885	0.249%	10.047

> That the sample rate is ending up at ~10 Milliseconds, indicates some
> high frequency (>= 100Hz) events on those CPUs. Those events, apparently,
> take very little CPU time to complete, hence a load of about 1% on average.
>
> By the way, I can recreate the high sample rate with virtually no load
> on my system easy, but so far have been unable to get the high CPU
> frequencies observed by Jörg. I can get my system to about a target pstate of
> 20 where it should have remained at 16, but that is about it.
>
>> The driver is processing samples for idle task for every 10ms and
>> aperf/mperf are showing that we are always in turbo mode for idle task.
>
> That column pretty much always says "idle" (or swapper for my way of doing
> things). I have not found it to very useful as an indicator, and considerably
> more so since the utilization changes.
>
>>
>> Need to find out why idle task is not sleeping.
>
> I contend that is it.

Why?

Unless I misunderstood, because the trace data indicates that the those CPUs
are going into some deeper C stsate than C0 for most of their time.

... Doug

[toc] | [prev] | [next] | [standalone]

#1369668

From	"Rafael J. Wysocki" <rafael@kernel.org>
Date	2016-04-02 02:30 +0200
Message-ID	<rjhBU-3Nd-3@gated-at.bofh.it>
In reply to	#1369660

On Sat, Apr 2, 2016 at 1:36 AM, Doug Smythies <dsmythies@telus.net> wrote:
> On 2016.04.01 12:54 Rafael J. Wysocki wrote:
>>On Fri, Apr 1, 2016 at 8:31 PM, Doug Smythies <dsmythies@telus.net> wrote:
>>> On 2106.034.01 10:45 Srinivas Pandruvada wrote:
>>>> On Fri, 2016-04-01 at 16:06 +0200, Jörg Otte wrote:
>>> > > > > >
>>>>> Done. Attached the tracer.
>>>>> For me it looks like the previous one of the failing case.
>>>>
>>>> The traces show that idle task is constantly running without sleep.
>>>
>>> No, they (at least the first one, I didn't look at the next one yet)
>>> show that CPUs 2 and 3 are spending around 99% of their time not in state
>>> C0.
>
>> How do you figure that out if I may ask?  It is not so obvious to me
>> to be honest.
>
> The trace was not in the form for the post processing tools, so I had
> to manually import the trace into a spreadsheet and manually add new columns
> calculated from the others.
>
> Load = mperf / tsc * 100 % = C0 time.
> Duration (mS) = tsc / 2.5e9 * 1000
> Note: I do not recall seeing an exact tsc for Jörg's computer, so I used
> The 2.5 GHz from the device spec from some earlier e-mail.
>
> Example (formatting will likely not send O.K.):
>
>                 CPU#    time            core_busy       scaled  from    to      mperf           aperf           tsc             freq            load            duration (ms)
> <idle>-0        [002]   465.879451:     100             96              26      26      1826656 1826710 25062693        2500073 7.288%  10.025
> <idle>-0        [003]   465.879484:     99              96              26      26      305796  305781  25147993        2499877 1.216%  10.059
> <idle>-0        [000]   465.885794:     100             96              26      26      975908  975951  32434672        2500110 3.009%  12.974
> <idle>-0        [001]   465.886898:     100             250             10      31      327356  327364  26673840        2500061 1.227%  10.670
> <idle>-0        [002]   465.889527:     100             96              26      26      205336  205365  25133396        2500353 0.817%  10.053
> <idle>-0        [003]   465.889555:     99              95              26      26      62544           62341           25117916        2491885 0.249%  10.047

OK

It could be C1 with relatively short periods spent in it.

>> That the sample rate is ending up at ~10 Milliseconds, indicates some
>> high frequency (>= 100Hz) events on those CPUs. Those events, apparently,
>> take very little CPU time to complete, hence a load of about 1% on average.
>>
>> By the way, I can recreate the high sample rate with virtually no load
>> on my system easy, but so far have been unable to get the high CPU
>> frequencies observed by Jörg. I can get my system to about a target pstate of
>> 20 where it should have remained at 16, but that is about it.
>>
>>> The driver is processing samples for idle task for every 10ms and
>>> aperf/mperf are showing that we are always in turbo mode for idle task.
>>
>> That column pretty much always says "idle" (or swapper for my way of doing
>> things). I have not found it to very useful as an indicator, and considerably
>> more so since the utilization changes.
>>
>>>
>>> Need to find out why idle task is not sleeping.
>>
>> I contend that is it.
>
> Why?
>
> Unless I misunderstood, because the trace data indicates that the those CPUs
> are going into some deeper C stsate than C0 for most of their time.

But how long do they stay in those states every time?

Average residencies need to be well below 10 ms for the trace to be
produced every 10 ms, so the question seems to be what kicks the CPUs
out of idle states so often.  On a completely idle system, that's
highly suspicious.

[toc] | [prev] | [next] | [standalone]

#1369580

From	"Rafael J. Wysocki" <rafael@kernel.org>
Date	2016-04-01 22:30 +0200
Message-ID	<rjdRE-18Z-15@gated-at.bofh.it>
In reply to	#1369340

On Fri, Apr 1, 2016 at 4:06 PM, Jörg Otte <jrg.otte@gmail.com> wrote:
> 2016-04-01 14:40 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>> On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote:
>>> 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>>> > On Thursday, March 31, 2016 05:25:18 PM Jörg Otte wrote:
>>> >> 2016-03-31 13:42 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>>> >> > On Thursday, March 31, 2016 11:05:56 AM Jörg Otte wrote:
>>> >> >

[cut]

>
> Done. Attached the tracer.
> For me it looks like the previous one of the failing case.
>

Yes, it does, so no improvement.

Well, that will require further investigation, so I have created a
kernel Bugzilla entry for the tracking of this issue:

https://bugzilla.kernel.org/show_bug.cgi?id=115771

I would like to communicate through it going forward if that's not a problem.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1369422 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

From	"Doug Smythies" <dsmythies@telus.net>
Date	2016-04-01 17:30 +0200
Subject	RE: [intel-pstate driver regression] processor frequency very high even if in idle
Message-ID	<rj9bk-6jH-21@gated-at.bofh.it>
In reply to	#1369258

On 2016.04.01 05:40 Rafael J. Wysocki wrote:
> On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote:
>> 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>>> On Thursday, March 31, 2016 05:25:18 PM Jörg Otte wrote:
>>>> 2016-03-31 13:42 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>>>>> On Thursday, March 31, 2016 11:05:56 AM Jörg Otte wrote:

>> 
>> here they are.
>> 

> First of all, the sampling mechanics works as expected
> in the failing case, which is the most important thing
> I wanted to know.

Yes, but that might be part of the problem, as for some CPUs
there is never a long duration, and thus the long duration
check never kicks in driving the target pstate down.

> The core_busy column is clearly suspicious and it
> looks like CPUs 2 and 3 never really go idle.

This has been observed several times before [1].
Due to beat frequencies between desktop type frame rates
and such, the worst manifestation of the issue seems to be
for 300 Hz kernels, but Ubuntu uses uses 250 Hz.

Oh look, Jörg is using 300 Hz!!

$ grep CONFIG_HZ .config_jorg
# CONFIG_HZ_PERIODIC is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300

> I guess we'll need to find out
> why they don't go idle to get to the bottom of this, but it firmly falls into
> the weird stuff territory already.

I'm compiling a 300 Hz kernel now, also with "# CONFIG_NO_HZ is not set",
but I have never been able to re-create these type of findings before.

I have also tried several other things in an attempt re-create Jörg's
Case, so far without success.

References:
[1] https://bugzilla.kernel.org/show_bug.cgi?id=93521
In particular:
https://bugzilla.kernel.org/show_bug.cgi?id=93521#c35
https://bugzilla.kernel.org/show_bug.cgi?id=93521#c42
https://bugzilla.kernel.org/show_bug.cgi?id=93521#c77

... Doug

[toc] | [prev] | [next] | [standalone]

#1369482

From	Jörg Otte <jrg.otte@gmail.com>
Date	2016-04-01 18:50 +0200
Message-ID	<rjaqK-7af-13@gated-at.bofh.it>
In reply to	#1369422

2016-04-01 17:20 GMT+02:00 Doug Smythies <dsmythies@telus.net>:
> On 2016.04.01 05:40 Rafael J. Wysocki wrote:
>> On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote:
>>> 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>>>> On Thursday, March 31, 2016 05:25:18 PM Jörg Otte wrote:
>>>>> 2016-03-31 13:42 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>>>>>> On Thursday, March 31, 2016 11:05:56 AM Jörg Otte wrote:
>
>>>
>>> here they are.
>>>
>
>> First of all, the sampling mechanics works as expected
>> in the failing case, which is the most important thing
>> I wanted to know.
>
> Yes, but that might be part of the problem, as for some CPUs
> there is never a long duration, and thus the long duration
> check never kicks in driving the target pstate down.
>
>> The core_busy column is clearly suspicious and it
>> looks like CPUs 2 and 3 never really go idle.
>
> This has been observed several times before [1].
> Due to beat frequencies between desktop type frame rates
> and such, the worst manifestation of the issue seems to be
> for 300 Hz kernels, but Ubuntu uses uses 250 Hz.
>
> Oh look, Jörg is using 300 Hz!!
>
> $ grep CONFIG_HZ .config_jorg
> # CONFIG_HZ_PERIODIC is not set
> # CONFIG_HZ_100 is not set
> # CONFIG_HZ_250 is not set
> CONFIG_HZ_300=y
> # CONFIG_HZ_1000 is not set
> CONFIG_HZ=300
>

I use 300Hz because of:
"250 Hz is a good compromise choice allowing server performance
while also showing good interactive responsiveness even
on SMP and NUMA systems. If you are going to be using NTSC video
or multimedia, selected 300Hz instead." (from KBuild helptext)

-> I often use multimedia so according this text 300 Hz is the better
choice.

>> I guess we'll need to find out
>> why they don't go idle to get to the bottom of this, but it firmly falls into
>> the weird stuff territory already.

> I'm compiling a 300 Hz kernel now, also with "# CONFIG_NO_HZ is not set",

Again from KBuild helptext:
"CONFIG_NO_HZ:
This is the old config entry that enables dynticks idle.
We keep it around for a little while to enforce backward
compatibility with older config files."

-> NO_HZ outdated.

> but I have never been able to re-create these type of findings before.
>
> I have also tried several other things in an attempt re-create Jörg's
> Case, so far without success.
>
> References:
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=93521
> In particular:
> https://bugzilla.kernel.org/show_bug.cgi?id=93521#c35
> https://bugzilla.kernel.org/show_bug.cgi?id=93521#c42
> https://bugzilla.kernel.org/show_bug.cgi?id=93521#c77
>
> ... Doug


Nevertheless, I'll try setting 250Hz + NO_HZ

Thanks, Jörg

[toc] | [prev] | [next] | [standalone]

#1369498

From	Jörg Otte <jrg.otte@gmail.com>
Date	2016-04-01 19:40 +0200
Message-ID	<rjbd9-7LP-5@gated-at.bofh.it>
In reply to	#1369482

2016-04-01 18:46 GMT+02:00 Jörg Otte <jrg.otte@gmail.com>:
> 2016-04-01 17:20 GMT+02:00 Doug Smythies <dsmythies@telus.net>:
>> On 2016.04.01 05:40 Rafael J. Wysocki wrote:
>>> On Friday, April 01, 2016 11:20:42 AM Jörg Otte wrote:
>>>> 2016-03-31 17:43 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>>>>> On Thursday, March 31, 2016 05:25:18 PM Jörg Otte wrote:
>>>>>> 2016-03-31 13:42 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>>>>>>> On Thursday, March 31, 2016 11:05:56 AM Jörg Otte wrote:
>>
>>>>
>>>> here they are.
>>>>
>>
>>> First of all, the sampling mechanics works as expected
>>> in the failing case, which is the most important thing
>>> I wanted to know.
>>
>> Yes, but that might be part of the problem, as for some CPUs
>> there is never a long duration, and thus the long duration
>> check never kicks in driving the target pstate down.
>>
>>> The core_busy column is clearly suspicious and it
>>> looks like CPUs 2 and 3 never really go idle.
>>
>> This has been observed several times before [1].
>> Due to beat frequencies between desktop type frame rates
>> and such, the worst manifestation of the issue seems to be
>> for 300 Hz kernels, but Ubuntu uses uses 250 Hz.
>>
>> Oh look, Jörg is using 300 Hz!!
>>
>> $ grep CONFIG_HZ .config_jorg
>> # CONFIG_HZ_PERIODIC is not set
>> # CONFIG_HZ_100 is not set
>> # CONFIG_HZ_250 is not set
>> CONFIG_HZ_300=y
>> # CONFIG_HZ_1000 is not set
>> CONFIG_HZ=300
>>
>
> I use 300Hz because of:
> "250 Hz is a good compromise choice allowing server performance
> while also showing good interactive responsiveness even
> on SMP and NUMA systems. If you are going to be using NTSC video
> or multimedia, selected 300Hz instead." (from KBuild helptext)
>
> -> I often use multimedia so according this text 300 Hz is the better
> choice.
>
>>> I guess we'll need to find out
>>> why they don't go idle to get to the bottom of this, but it firmly falls into
>>> the weird stuff territory already.
>
>> I'm compiling a 300 Hz kernel now, also with "# CONFIG_NO_HZ is not set",
>
> Again from KBuild helptext:
> "CONFIG_NO_HZ:
> This is the old config entry that enables dynticks idle.
> We keep it around for a little while to enforce backward
> compatibility with older config files."
>
> -> NO_HZ outdated.
>
>> but I have never been able to re-create these type of findings before.
>>
>> I have also tried several other things in an attempt re-create Jörg's
>> Case, so far without success.
>>
>> References:
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=93521
>> In particular:
>> https://bugzilla.kernel.org/show_bug.cgi?id=93521#c35
>> https://bugzilla.kernel.org/show_bug.cgi?id=93521#c42
>> https://bugzilla.kernel.org/show_bug.cgi?id=93521#c77
>>
>> ... Doug
>
>
> Nevertheless, I'll try setting 250Hz + NO_HZ
>
For me no improvements.
Neither 300->250Hz  nor  NO_HZ_IDLE + NO_HZ

Thanks, Jörg

[toc] | [prev] | [next] | [standalone]

#1367308

From	"Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>
Date	2016-03-30 17:40 +0200
Message-ID	<riqnU-7t2-17@gated-at.bofh.it>
In reply to	#1367106

On Wed, 2016-03-30 at 13:05 +0200, Rafael J. Wysocki wrote:
> On Wed, Mar 30, 2016 at 12:17 PM, Jörg Otte <jrg.otte@gmail.com>
> wrote:
> > 
> > 2016-03-29 23:34 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
> > > 
> > > On Tuesday, March 29, 2016 07:32:27 PM Jörg Otte wrote:
> > > > 
> > > > 2016-03-29 19:24 GMT+02:00 Jörg Otte <jrg.otte@gmail.com>:
> > > > > 
> > > > > in v4.5 and earlier intel-pstate downscaled idle processors
> > > > > (load
> > > > > 0.1-0.2%) to minumum frequency, in my case 800MHz.
> > > > > 
> > > > > Now in v4.6-rc1 the characteristic has dramatically changed.
> > > > > If in
> > > > > idle the processor frequency is more or less a few MHz around
> > > > > 2500Mhz.
> > > > > This is the maximum non turbo frequency.
> > > > > 
> > > > > No difference between powersafe or performance governor.
> > > > > 
> > > > > I currently use acpi_cpufreq which works as usual.
> > > > > 
> > > > > Processor:
> > > > > Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz (family: 0x6, model:
> > > > > 0x3c,
> > > > > stepping: 0x3)
> > > > > 
> > > > > Last known good kernel is: 4.5.0-01127-g9256d5a
> > > > > First known bad kernel is: 4.5.0-02535-g09fd671
> > > > > 
> > > > > There is
> > > > > commit 277edba Merge tag 'pm+acpi-4.6-rc1-1' of
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> > > > > in between, which brought a few changes in intel_pstate.
> > > Can you please check commit a4675fbc4a7a (cpufreq: intel_pstate:
> > > Replace timers
> > > with utilization update callbacks)?
> > > 
> > Yes , this solved the problem for me.
> > I had to resolve some conflicts myself when reverting that
> > commit. Hard work :).
> Thanks for doing this.  Can you please post the revert patch you have
> used?
> 
> > 
> > Here is a 10-seconds trace of the used frequencies when
> > in "desktop-idle":
> > 
> > driver          cpu0 cpu1 cpu2 cpu3
> > -------------------------------------
> > intel_pstate (  800  928  941 1200) MHz   load:( 0.2)%
> > intel_pstate (  800  928 1181 1800) MHz   load:( 0.0)%
> > intel_pstate ( 1675 1576 1347  800) MHz   load:( 0.0)%
> > intel_pstate ( 1198 1576  842  800) MHz   load:( 0.5)%
> > intel_pstate (  800 1181 1113 1600) MHz   load:( 0.0)%
> > intel_pstate (  808 1181  805  800) MHz   load:( 0.5)%
> > intel_pstate (  844 1191  900 1082) MHz   load:( 0.3)%
> > intel_pstate (  816 1191  800  800) MHz   load:( 0.0)%
> > intel_pstate (  800  905  892 1082) MHz   load:( 0.2)%
> > intel_pstate (  945  905 1340  800) MHz   load:( 0.3)%
> Please also run turbostat with and without your revert patch applied.
I want to reproduce this if I can. Can you give us info about your
setup (Linux distribution, laptop model etc.)?

Thanks,
Srinivas

> 
> Thanks,
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1367328

From	Jörg Otte <jrg.otte@gmail.com>
Date	2016-03-30 18:00 +0200
Message-ID	<riqHh-7AW-43@gated-at.bofh.it>
In reply to	#1367308

2016-03-30 17:33 GMT+02:00 Pandruvada, Srinivas <srinivas.pandruvada@intel.com>:
> On Wed, 2016-03-30 at 13:05 +0200, Rafael J. Wysocki wrote:
>> On Wed, Mar 30, 2016 at 12:17 PM, Jörg Otte <jrg.otte@gmail.com>
>> wrote:
>> >
>> > 2016-03-29 23:34 GMT+02:00 Rafael J. Wysocki <rjw@rjwysocki.net>:
>> > >
>> > > On Tuesday, March 29, 2016 07:32:27 PM Jörg Otte wrote:
>> > > >
>> > > > 2016-03-29 19:24 GMT+02:00 Jörg Otte <jrg.otte@gmail.com>:
>> > > > >
>> > > > > in v4.5 and earlier intel-pstate downscaled idle processors
>> > > > > (load
>> > > > > 0.1-0.2%) to minumum frequency, in my case 800MHz.
>> > > > >
>> > > > > Now in v4.6-rc1 the characteristic has dramatically changed.
>> > > > > If in
>> > > > > idle the processor frequency is more or less a few MHz around
>> > > > > 2500Mhz.
>> > > > > This is the maximum non turbo frequency.
>> > > > >
>> > > > > No difference between powersafe or performance governor.
>> > > > >
>> > > > > I currently use acpi_cpufreq which works as usual.
>> > > > >
>> > > > > Processor:
>> > > > > Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz (family: 0x6, model:
>> > > > > 0x3c,
>> > > > > stepping: 0x3)
>> > > > >
>> > > > > Last known good kernel is: 4.5.0-01127-g9256d5a
>> > > > > First known bad kernel is: 4.5.0-02535-g09fd671
>> > > > >
>> > > > > There is
>> > > > > commit 277edba Merge tag 'pm+acpi-4.6-rc1-1' of
>> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
>> > > > > in between, which brought a few changes in intel_pstate.
>> > > Can you please check commit a4675fbc4a7a (cpufreq: intel_pstate:
>> > > Replace timers
>> > > with utilization update callbacks)?
>> > >
>> > Yes , this solved the problem for me.
>> > I had to resolve some conflicts myself when reverting that
>> > commit. Hard work :).
>> Thanks for doing this.  Can you please post the revert patch you have
>> used?
>>
>> >
>> > Here is a 10-seconds trace of the used frequencies when
>> > in "desktop-idle":
>> >
>> > driver          cpu0 cpu1 cpu2 cpu3
>> > -------------------------------------
>> > intel_pstate (  800  928  941 1200) MHz   load:( 0.2)%
>> > intel_pstate (  800  928 1181 1800) MHz   load:( 0.0)%
>> > intel_pstate ( 1675 1576 1347  800) MHz   load:( 0.0)%
>> > intel_pstate ( 1198 1576  842  800) MHz   load:( 0.5)%
>> > intel_pstate (  800 1181 1113 1600) MHz   load:( 0.0)%
>> > intel_pstate (  808 1181  805  800) MHz   load:( 0.5)%
>> > intel_pstate (  844 1191  900 1082) MHz   load:( 0.3)%
>> > intel_pstate (  816 1191  800  800) MHz   load:( 0.0)%
>> > intel_pstate (  800  905  892 1082) MHz   load:( 0.2)%
>> > intel_pstate (  945  905 1340  800) MHz   load:( 0.3)%
>> Please also run turbostat with and without your revert patch applied.
> I want to reproduce this if I can. Can you give us info about your
> setup (Linux distribution, laptop model etc.)?
>
> Thanks,
> Srinivas

Distro: Ubuntu 14.04.4 LTS
Laptop: FUJITSU LIFEBOOK A544

lspci:
=======
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core
Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB xHCI (rev 04)
00:16.0 Communication controller: Intel Corporation 8 Series/C220
Series Chipset Family MEI Controller #1 (rev 04)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset
High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #1 (rev d4)
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #3 (rev d4)
00:1c.5 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #6 (rev d4)
00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series
Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family
SMBus Controller (rev 04)
00:1f.6 Signal processing controller: Intel Corporation 8 Series
Chipset Family Thermal Management Controller (rev 04)
03:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)

lshw:
========
    description: Notebook
    product: LIFEBOOK A544 ()
    vendor: FUJITSU
    serial: YLUA094704
    width: 64 bits
    capabilities: smbios-2.7 dmi-2.7
    configuration: administrator_password=disabled boot=normal
chassis=notebook frontpanel_password=disabled
keyboard_password=disabled power-on_password=disabled
uuid=F4FC89BC-8701-1230-8B14-E01877C1801D
  *-core
       description: Motherboard
       product: FJNBB35
       vendor: FUJITSU
       physical id: 0
       serial: 651583-01R4712766
     *-cpu
          description: CPU
          product: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
          vendor: Intel Corp.
          physical id: 0
          bus info: cpu@0
          version: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
          serial: To Be Filled By O.E.M.
          slot: On Board
          size: 2500MHz
          capacity: 2500MHz
          width: 64 bits
          clock: 100MHz
          capabilities: x86-64 fpu fpu_exception wp vme de pse tsc msr
pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx
fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp constant_tsc
arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf
eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg
fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer
aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority
ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
dtherm ida arat pln pts cpufreq
          configuration: cores=2 enabledcores=2 threads=4
        *-cache:0
             description: L1 cache
             physical id: 2
             slot: L1-Cache
             size: 32KiB
             capacity: 32KiB
             capabilities: asynchronous internal write-back instruction
        *-cache:1
             description: L2 cache
             physical id: 3
             slot: L2-Cache
             size: 256KiB
             capacity: 256KiB
             capabilities: asynchronous internal write-back unified
        *-cache:2
             description: L3 cache
             physical id: 4
             slot: L3-Cache
             size: 3MiB
             capacity: 3MiB
             capabilities: asynchronous internal write-back unified
     *-cache
          description: L1 cache
          physical id: 1
          slot: L1-Cache
          size: 32KiB
          capacity: 32KiB
          capabilities: asynchronous internal write-back data
     *-memory
          description: System Memory
          physical id: 5
          slot: System board or motherboard
          size: 8GiB
        *-bank:0
             description: SODIMM DDR3 Synchronous 1600 MHz (0,6 ns)
             product: M471B1G73DB0-YK0
             vendor: Samsung
             physical id: 0
             serial: 57641925
             slot: ChannelA-DIMM0
             size: 8GiB
             width: 64 bits
             clock: 1600MHz (0.6ns)
        *-bank:1
             description: DIMM [empty]
             physical id: 1
             slot: ChannelA-DIMM1
        *-bank:2
             description: DIMM [empty]
             physical id: 2
             slot: ChannelB-DIMM0
        *-bank:3
             description: DIMM [empty]
             physical id: 3
             slot: ChannelB-DIMM1
     *-firmware
          description: BIOS
          vendor: FUJITSU // Phoenix Technologies Ltd.
          physical id: 25
          version: Version 1.17
          date: 05/09/2014
          size: 128KiB
          capacity: 4032KiB
          capabilities: pci pcmcia pnp upgrade shadowing cdboot
bootselect acpi usb biosbootspecification netboot
     *-pci
          description: Host bridge
          product: Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller
          vendor: Intel Corporation
          physical id: 100
          bus info: pci@0000:00:00.0
          version: 06
          width: 32 bits
          clock: 33MHz
        *-pci:0
             description: PCI bridge
             product: Xeon E3-1200 v3/4th Gen Core Processor PCI
Express x16 Controller
             vendor: Intel Corporation
             physical id: 1
             bus info: pci@0000:00:01.0
             version: 06
             width: 32 bits
             clock: 33MHz
             capabilities: pci pm msi pciexpress normal_decode
bus_master cap_list
             configuration: driver=pcieport
             resources: irq:16
        *-display
             description: VGA compatible controller
             product: 4th Gen Core Processor Integrated Graphics Controller
             vendor: Intel Corporation
             physical id: 2
             bus info: pci@0000:00:02.0
             version: 06
             width: 64 bits
             clock: 33MHz
             capabilities: msi pm vga_controller bus_master cap_list rom
             configuration: driver=i915 latency=0
             resources: irq:24 memory:f0000000-f03fffff
memory:e0000000-efffffff ioport:4000(size=64) memory:c0000-dffff
        *-multimedia:0 UNCLAIMED
             description: Audio device
             product: Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller
             vendor: Intel Corporation
             physical id: 3
             bus info: pci@0000:00:03.0
             version: 06
             width: 64 bits
             clock: 33MHz
             capabilities: pm msi pciexpress bus_master cap_list
             configuration: latency=0
             resources: memory:f0710000-f0713fff
        *-usb
             description: USB controller
             product: 8 Series/C220 Series Chipset Family USB xHCI
             vendor: Intel Corporation
             physical id: 14
             bus info: pci@0000:00:14.0
             version: 04
             width: 64 bits
             clock: 33MHz
             capabilities: pm msi xhci bus_master cap_list
             configuration: driver=xhci_hcd latency=0
             resources: irq:28 memory:f0700000-f070ffff
        *-communication UNCLAIMED
             description: Communication controller
             product: 8 Series/C220 Series Chipset Family MEI Controller #1
             vendor: Intel Corporation
             physical id: 16
             bus info: pci@0000:00:16.0
             version: 04
             width: 64 bits
             clock: 33MHz
             capabilities: pm msi bus_master cap_list
             configuration: latency=0
             resources: memory:f0719000-f071900f
        *-multimedia:1 UNCLAIMED
             description: Audio device
             product: 8 Series/C220 Series Chipset High Definition
Audio Controller
             vendor: Intel Corporation
             physical id: 1b
             bus info: pci@0000:00:1b.0
             version: 04
             width: 64 bits
             clock: 33MHz
             capabilities: pm msi pciexpress bus_master cap_list
             configuration: latency=0
             resources: memory:f0714000-f0717fff
        *-pci:1
             description: PCI bridge
             product: 8 Series/C220 Series Chipset Family PCI Express
Root Port #1
             vendor: Intel Corporation
             physical id: 1c
             bus info: pci@0000:00:1c.0
             version: d4
             width: 32 bits
             clock: 33MHz
             capabilities: pci pciexpress msi pm normal_decode
bus_master cap_list
             configuration: driver=pcieport
             resources: irq:16
        *-pci:2
             description: PCI bridge
             product: 8 Series/C220 Series Chipset Family PCI Express
Root Port #3
             vendor: Intel Corporation
             physical id: 1c.2
             bus info: pci@0000:00:1c.2
             version: d4
             width: 32 bits
             clock: 33MHz
             capabilities: pci pciexpress msi pm normal_decode
bus_master cap_list
             configuration: driver=pcieport
             resources: irq:18 memory:f0600000-f06fffff
           *-network DISABLED
                description: Ethernet interface
                product: Wireless 7260
                vendor: Intel Corporation
                physical id: 0
                bus info: pci@0000:03:00.0
                logical name: wlan0
                version: 73
                serial: 80:19:34:4d:31:40
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi pciexpress bus_master cap_list
ethernet physical
                configuration: broadcast=yes driver=iwlwifi
driverversion=4.5.0-reva4675fbc4a7a-02536-g77 firmware=16.242414.0
latency=0 link=no multicast=yes
                resources: irq:27 memory:f0600000-f0601fff
        *-pci:3
             description: PCI bridge
             product: 8 Series/C220 Series Chipset Family PCI Express
Root Port #6
             vendor: Intel Corporation
             physical id: 1c.5
             bus info: pci@0000:00:1c.5
             version: d4
             width: 32 bits
             clock: 33MHz
             capabilities: pci pciexpress msi pm normal_decode
bus_master cap_list
             configuration: driver=pcieport
             resources: irq:17 ioport:3000(size=4096)
memory:f0500000-f05fffff ioport:f0400000(size=1048576)
           *-network
                description: Ethernet interface
                product: RTL8111/8168/8411 PCI Express Gigabit
Ethernet Controller
                vendor: Realtek Semiconductor Co., Ltd.
                physical id: 0
                bus info: pci@0000:04:00.0
                logical name: eth0
                version: 07
                serial: e0:18:77:c1:80:1d
                size: 1Gbit/s
                capacity: 1Gbit/s
                width: 64 bits
                clock: 33MHz
                capabilities: pm msi pciexpress msix vpd bus_master
cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt
1000bt-fd autonegotiation
                configuration: autonegotiation=on broadcast=yes
driver=r8169 driverversion=2.3LK-NAPI duplex=full
firmware=rtl8168e-3_0.0.4 03/27/12 ip=192.168.0.18 latency=0 link=yes
multicast=yes port=MII speed=1Gbit/s
                resources: irq:26 ioport:3000(size=256)
memory:f0500000-f0500fff memory:f0400000-f0403fff
        *-isa
             description: ISA bridge
             product: HM86 Express LPC Controller
             vendor: Intel Corporation
             physical id: 1f
             bus info: pci@0000:00:1f.0
             version: 04
             width: 32 bits
             clock: 33MHz
             capabilities: isa bus_master cap_list
             configuration: latency=0
        *-storage
             description: SATA controller
             product: 8 Series/C220 Series Chipset Family 6-port SATA
Controller 1 [AHCI mode]
             vendor: Intel Corporation
             physical id: 1f.2
             bus info: pci@0000:00:1f.2
             version: 04
             width: 32 bits
             clock: 66MHz
             capabilities: storage msi pm ahci_1.0 bus_master cap_list
             configuration: driver=ahci latency=0
             resources: irq:25 ioport:4088(size=8) ioport:4094(size=4)
ioport:4080(size=8) ioport:4090(size=4) ioport:4060(size=32)
memory:f071c000-f071c7ff
        *-serial UNCLAIMED
             description: SMBus
             product: 8 Series/C220 Series Chipset Family SMBus Controller
             vendor: Intel Corporation
             physical id: 1f.3
             bus info: pci@0000:00:1f.3
             version: 04
             width: 64 bits
             clock: 33MHz
             configuration: latency=0
             resources: memory:f0718000-f07180ff ioport:efa0(size=32)
        *-generic UNCLAIMED
             description: Signal processing controller
             product: 8 Series Chipset Family Thermal Management Controller
             vendor: Intel Corporation
             physical id: 1f.6
             bus info: pci@0000:00:1f.6
             version: 04
             width: 64 bits
             clock: 33MHz
             capabilities: pm msi bus_master cap_list
             configuration: latency=0
             resources: memory:f071b000-f071bfff
     *-scsi:0
          physical id: 2
          bus info: usb@2:1
          logical name: scsi6
          capabilities: emulated scsi-host
          configuration: driver=usb-storage
        *-disk
             description: SCSI Disk
             product: ASM1153E
             vendor: asmedia
             physical id: 0.0.0
             bus info: scsi@6:0.0.0
             logical name: /dev/sda
             version: 0
             serial: 2109876543210
             size: 698GiB (750GB)
             capabilities: partitioned partitioned:dos
             configuration: ansiversion=6 sectorsize=4096 signature=000a8c30
           *-volume
                description: EXT4 volume
                vendor: Linux
                physical id: 1
                bus info: scsi@6:0.0.0,1
                logical name: /dev/sda1
                logical name: /media/jojo/deftoshiba
                version: 1.0
                serial: b5dcbf60-26b0-42b5-af73-ce0cb2f8dbcb
                size: 698GiB
                capacity: 698GiB
                capabilities: primary journaled extended_attributes
large_files huge_files dir_nlink recover extents ext4 ext2 initialized
                configuration: created=2016-03-07 17:41:49
filesystem=ext4 label=deftoshiba lastmountpoint=/media/jojo/deftoshiba
modified=2016-03-30 17:05:24 mount.fstype=ext4
mount.options=rw,nosuid,nodev,relatime,data=ordered mounted=2016-03-30
17:05:24 state=mounted
     *-scsi:1
          physical id: 3
          logical name: scsi2
          capabilities: emulated
        *-cdrom
             description: DVD-RAM writer
             product: CDDVDW SU-208CB
             vendor: TSSTcorp
             physical id: 0.0.0
             bus info: scsi@2:0.0.0
             logical name: /dev/cdrom
             logical name: /dev/sr0
             version: FU01
             capabilities: removable audio cd-r cd-rw dvd dvd-r dvd-ram
             configuration: ansiversion=5 status=nodisc
     *-scsi:2
          physical id: 4
          logical name: scsi4
          capabilities: emulated
        *-disk
             description: ATA Disk
             product: ST500LM000-1EJ16
             vendor: Seagate
             physical id: 0.0.0
             bus info: scsi@4:0.0.0
             logical name: /dev/sdb
             version: FJ14
             serial: W761H3BD
             size: 465GiB (500GB)
             capabilities: gpt-1.00 partitioned partitioned:gpt
             configuration: ansiversion=5
guid=a08a4503-fae4-4a5b-b677-5c66cbbff634 sectorsize=4096
           *-volume:0
                description: Windows FAT volume
                vendor: mkfs.fat
                physical id: 1
                bus info: scsi@4:0.0.0,1
                logical name: /dev/sdb1
                logical name: /boot/efi
                version: FAT32
                serial: 8b74-4e15
                size: 510MiB
                capacity: 511MiB
                capabilities: boot fat initialized
                configuration: FATs=2 filesystem=fat mount.fstype=vfat
mount.options=rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
state=mounted
           *-volume:1
                description: EXT4 volume
                vendor: Linux
                physical id: 2
                bus info: scsi@4:0.0.0,2
                logical name: /dev/sdb2
                logical name: /
                version: 1.0
                serial: 17ed5f3c-77aa-4dbe-992b-88c943eb9c4e
                size: 457GiB
                capabilities: journaled extended_attributes
large_files huge_files dir_nlink recover extents ext4 ext2 initialized
                configuration: created=2015-10-22 11:13:27
filesystem=ext4 lastmountpoint=/ modified=2016-03-30 17:04:26
mount.fstype=ext4
mount.options=rw,relatime,errors=remount-ro,data=ordered
mounted=2016-03-30 17:04:26 state=mounted
           *-volume:2
                description: Linux swap volume
                vendor: Linux
                physical id: 3
                bus info: scsi@4:0.0.0,3
                logical name: /dev/sdb3
                version: 1
                serial: 8c1aad5c-b153-46db-884b-d0d38ba2f9ee
                size: 8097MiB
                capacity: 8098MiB
                capabilities: nofs swap initialized
                configuration: filesystem=swap pagesize=4095
  *-battery
       description: Lithium Ion Battery
       product: CP671396-01
       vendor: FUJITSU
       physical id: 1
       version: 2014/ 7/14
       serial: 01A-Z140714001338Z
       slot: Internal Battery
       capacity: 48600mWh
       configuration: voltage=10,8V

[toc] | [prev] | [next] | [standalone]

#1367519

From	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date	2016-03-30 21:00 +0200
Message-ID	<ritvs-1a3-7@gated-at.bofh.it>
In reply to	#1367328

On Wed, 2016-03-30 at 11:50 -0700, Doug Smythies wrote:
> On 2016.03.30 08:52 Jörg Otte wrote:
> > 
> > 2016-03-30 17:33 GMT+02:00 Pandruvada, Srinivas <srinivas.pandruvad
> > a@intel.com>:
> > > 
> > > On Wed, 2016-03-30 at 13:05 +0200, Rafael J. Wysocki wrote:
> > > > 
> > > > On Wed, Mar 30, 2016 at 12:17 PM, Jörg Otte <jrg.otte@gmail.com
> > > > >
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Now in v4.6-rc1 the characteristic has dramatically
> > > > > > > changed.
> > > > > > > If in idle the processor frequency is more or less a few
> > > > > > > MHz around 2500Mhz.
> > > > > > > I currently use acpi_cpufreq which works as usual.
> > > > > > > Processor: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
> > > > > > > (family: 0x6, model: 0x3c, stepping: 0x3)
> > 
> > > 
> > > I want to reproduce this if I can. Can you give us info about
> > > your
> > > setup (Linux distribution, laptop model etc.)?
> I would like to try to reproduce the issue also.
> 
> > 
> > Distro: Ubuntu 14.04.4 LTS
> Note that with Ubuntu 14.04, I had issues where my CPU
> would lock at pstate 24 (not always 24, but usually),
> regardless of load.
> However, it was always after an S3 suspend, occurred 100%
> of the time, and was independent of intel_pstate or
> acpi-cpufreq CPU frequency scaling drivers.
> 
> Since changing my test server to Ubuntu server edition 16.04
> (development version), I have not had those issues. While I have
> no proof, I have assumed the issue elimination was somehow related
> to the change to systemd.
> 
> It might be worth observing both what the intel_pstate is asking for
> and what the processor is actually doing.

If Jörg runs with

turbostat -i 1 --msr=0x199

We can tell whether if we requested or the same problem you had.
I tried on Ubuntu LTS 14.04 on same Haswell CPU model, I didn't see
this issue.

Thanks,
Srinivas

[toc] | [prev] | [next] | [standalone]

#1367577

From	"Rafael J. Wysocki" <rafael@kernel.org>
Date	2016-03-30 22:20 +0200
Message-ID	<riuKT-2cZ-29@gated-at.bofh.it>
In reply to	#1367519

On Wed, Mar 30, 2016 at 8:58 PM, Srinivas Pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
> On Wed, 2016-03-30 at 11:50 -0700, Doug Smythies wrote:
>> On 2016.03.30 08:52 Jörg Otte wrote:
>> >
>> > 2016-03-30 17:33 GMT+02:00 Pandruvada, Srinivas <srinivas.pandruvad
>> > a@intel.com>:
>> > >
>> > > On Wed, 2016-03-30 at 13:05 +0200, Rafael J. Wysocki wrote:
>> > > >
>> > > > On Wed, Mar 30, 2016 at 12:17 PM, Jörg Otte <jrg.otte@gmail.com
>> > > > >
>> >
>> > >
>> > > >
>> > > > >
>> > > > > >
>> > > > > > >
>> > > > > > > Now in v4.6-rc1 the characteristic has dramatically
>> > > > > > > changed.
>> > > > > > > If in idle the processor frequency is more or less a few
>> > > > > > > MHz around 2500Mhz.
>> > > > > > > I currently use acpi_cpufreq which works as usual.
>> > > > > > > Processor: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
>> > > > > > > (family: 0x6, model: 0x3c, stepping: 0x3)
>> >
>> > >
>> > > I want to reproduce this if I can. Can you give us info about
>> > > your
>> > > setup (Linux distribution, laptop model etc.)?
>> I would like to try to reproduce the issue also.
>>
>> >
>> > Distro: Ubuntu 14.04.4 LTS
>> Note that with Ubuntu 14.04, I had issues where my CPU
>> would lock at pstate 24 (not always 24, but usually),
>> regardless of load.
>> However, it was always after an S3 suspend, occurred 100%
>> of the time, and was independent of intel_pstate or
>> acpi-cpufreq CPU frequency scaling drivers.
>>
>> Since changing my test server to Ubuntu server edition 16.04
>> (development version), I have not had those issues. While I have
>> no proof, I have assumed the issue elimination was somehow related
>> to the change to systemd.
>>
>> It might be worth observing both what the intel_pstate is asking for
>> and what the processor is actually doing.
>
> If Jörg runs with
>
> turbostat -i 1 --msr=0x199
>
> We can tell whether if we requested or the same problem you had.
> I tried on Ubuntu LTS 14.04 on same Haswell CPU model, I didn't see
> this issue.

There seems to be something odd about the Jörg's setup, or we'd have
received more reports about this issue.

Question is what that is and what really makes the difference.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1367597

From	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date	2016-03-30 22:30 +0200
Message-ID	<riuUy-2hW-9@gated-at.bofh.it>
In reply to	#1367577

On Wed, 2016-03-30 at 22:12 +0200, Rafael J. Wysocki wrote:
> On Wed, Mar 30, 2016 at 8:58 PM, Srinivas Pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> > 
> > On Wed, 2016-03-30 at 11:50 -0700, Doug Smythies wrote:
> > > 
> > > On 2016.03.30 08:52 Jörg Otte wrote:
> > > > 
> > > > 
> > > > 2016-03-30 17:33 GMT+02:00 Pandruvada, Srinivas
> > > > <srinivas.pandruvad
> > > > a@intel.com>:
> > > > > 
> > > > > 
> > > > > On Wed, 2016-03-30 at 13:05 +0200, Rafael J. Wysocki wrote:
> > > > > > 
> > > > > > 
> > > > > > On Wed, Mar 30, 2016 at 12:17 PM, Jörg Otte <jrg.otte@gmail
> > > > > > .com
> > > > > > > 
> > > > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Now in v4.6-rc1 the characteristic has dramatically
> > > > > > > > > changed.
> > > > > > > > > If in idle the processor frequency is more or less a
> > > > > > > > > few
> > > > > > > > > MHz around 2500Mhz.
> > > > > > > > > I currently use acpi_cpufreq which works as usual.
> > > > > > > > > Processor: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
> > > > > > > > > (family: 0x6, model: 0x3c, stepping: 0x3)
> > > > > 
> > > > > 
> > > > > I want to reproduce this if I can. Can you give us info about
> > > > > your
> > > > > setup (Linux distribution, laptop model etc.)?
> > > I would like to try to reproduce the issue also.
> > > 
> > > > 
> > > > 
> > > > Distro: Ubuntu 14.04.4 LTS
> > > Note that with Ubuntu 14.04, I had issues where my CPU
> > > would lock at pstate 24 (not always 24, but usually),
> > > regardless of load.
> > > However, it was always after an S3 suspend, occurred 100%
> > > of the time, and was independent of intel_pstate or
> > > acpi-cpufreq CPU frequency scaling drivers.
> > > 
> > > Since changing my test server to Ubuntu server edition 16.04
> > > (development version), I have not had those issues. While I have
> > > no proof, I have assumed the issue elimination was somehow
> > > related
> > > to the change to systemd.
> > > 
> > > It might be worth observing both what the intel_pstate is asking
> > > for
> > > and what the processor is actually doing.
> > If Jörg runs with
> > 
> > turbostat -i 1 --msr=0x199
> > 
> > We can tell whether if we requested or the same problem you had.
> > I tried on Ubuntu LTS 14.04 on same Haswell CPU model, I didn't see
> > this issue.
> There seems to be something odd about the Jörg's setup, or we'd have
> received more reports about this issue.
> 
> Question is what that is and what really makes the difference.
> 
I think, somehow we entered performance mode from powersave by default

turbostat -i 1 --msr=0x199 will tell us. 

Thanks,
Srinivas

> Thanks,
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1368065

From	Jörg Otte <jrg.otte@gmail.com>
Date	2016-03-31 11:30 +0200
Message-ID	<riH5o-2PS-19@gated-at.bofh.it>
In reply to	#1367597

2016-03-30 22:26 GMT+02:00 Srinivas Pandruvada
<srinivas.pandruvada@linux.intel.com>:
> On Wed, 2016-03-30 at 22:12 +0200, Rafael J. Wysocki wrote:
>> On Wed, Mar 30, 2016 at 8:58 PM, Srinivas Pandruvada
>> <srinivas.pandruvada@linux.intel.com> wrote:
>> >
>> > On Wed, 2016-03-30 at 11:50 -0700, Doug Smythies wrote:
>> > >
>> > > On 2016.03.30 08:52 Jörg Otte wrote:
>> > > >
>> > > >
>> > > > 2016-03-30 17:33 GMT+02:00 Pandruvada, Srinivas
>> > > > <srinivas.pandruvad
>> > > > a@intel.com>:
>> > > > >
>> > > > >
>> > > > > On Wed, 2016-03-30 at 13:05 +0200, Rafael J. Wysocki wrote:
>> > > > > >
>> > > > > >
>> > > > > > On Wed, Mar 30, 2016 at 12:17 PM, Jörg Otte <jrg.otte@gmail
>> > > > > > .com
>> > > > > > >
>> > > > > > >
>> > > > >
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > Now in v4.6-rc1 the characteristic has dramatically
>> > > > > > > > > changed.
>> > > > > > > > > If in idle the processor frequency is more or less a
>> > > > > > > > > few
>> > > > > > > > > MHz around 2500Mhz.
>> > > > > > > > > I currently use acpi_cpufreq which works as usual.
>> > > > > > > > > Processor: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
>> > > > > > > > > (family: 0x6, model: 0x3c, stepping: 0x3)
>> > > > >
>> > > > >
>> > > > > I want to reproduce this if I can. Can you give us info about
>> > > > > your
>> > > > > setup (Linux distribution, laptop model etc.)?
>> > > I would like to try to reproduce the issue also.
>> > >
>> > > >
>> > > >
>> > > > Distro: Ubuntu 14.04.4 LTS
>> > > Note that with Ubuntu 14.04, I had issues where my CPU
>> > > would lock at pstate 24 (not always 24, but usually),
>> > > regardless of load.
>> > > However, it was always after an S3 suspend, occurred 100%
>> > > of the time, and was independent of intel_pstate or
>> > > acpi-cpufreq CPU frequency scaling drivers.
>> > >
>> > > Since changing my test server to Ubuntu server edition 16.04
>> > > (development version), I have not had those issues. While I have
>> > > no proof, I have assumed the issue elimination was somehow
>> > > related
>> > > to the change to systemd.
>> > >
>> > > It might be worth observing both what the intel_pstate is asking
>> > > for
>> > > and what the processor is actually doing.
>> > If Jörg runs with
>> >
>> > turbostat -i 1 --msr=0x199
>> >
>> > We can tell whether if we requested or the same problem you had.
>> > I tried on Ubuntu LTS 14.04 on same Haswell CPU model, I didn't see
>> > this issue.
>> There seems to be something odd about the Jörg's setup, or we'd have
>> received more reports about this issue.
>>
>> Question is what that is and what really makes the difference.
>>
> I think, somehow we entered performance mode from powersave by default
>
> turbostat -i 1 --msr=0x199 will tell us.
>

jojo@fichte:/sys/devices/system/cpu/cpufreq/policy0$ cat scaling_governor
powersave

turbostat -i 1 --msr=0x199
CPUID(7): No-SGX
     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
       -      45    1.74    2590    2496  0x00000000
       0      45    1.76    2565    2498  0x00000a00
       1      72    2.84    2548    2496  0x00000800
       2      30    1.11    2661    2496  0x00001a00
       3      33    1.23    2661    2495  0x00001a00
     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
       -       9    0.35    2525    2495  0x00000000
       0       1    0.04    2735    2495  0x00000800
       1       1    0.05    2501    2495  0x00000800
       2      17    0.65    2540    2495  0x00001a00
       3      16    0.64    2501    2495  0x00001a00
     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
       -      11    0.43    2523    2495  0x00000000
       0       3    0.11    2631    2495  0x00000c00
       1       7    0.27    2524    2495  0x00000800
       2      18    0.72    2527    2495  0x00001a00
       3      15    0.61    2501    2495  0x00001a00

Thanks, Jörg

[toc] | [prev] | [next] | [standalone]

#1368366 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

From	"Doug Smythies" <dsmythies@telus.net>
Date	2016-03-31 16:40 +0200
Subject	RE: [intel-pstate driver regression] processor frequency very high even if in idle
Message-ID	<riLVo-6qF-13@gated-at.bofh.it>
In reply to	#1368065

On 2016.03.31 02:24 Jörg Otte wrote:

> jojo@fichte:/sys/devices/system/cpu/cpufreq/policy0$ cat scaling_governor
> powersave
> 
> turbostat -i 1 --msr=0x199
> CPUID(7): No-SGX
>     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
>       -      45    1.74    2590    2496  0x00000000
>       0      45    1.76    2565    2498  0x00000a00
>       1      72    2.84    2548    2496  0x00000800
>       2      30    1.11    2661    2496  0x00001a00
>       3      33    1.23    2661    2495  0x00001a00
>     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
>       -       9    0.35    2525    2495  0x00000000
>       0       1    0.04    2735    2495  0x00000800
>       1       1    0.05    2501    2495  0x00000800
>       2      17    0.65    2540    2495  0x00001a00
>       3      16    0.64    2501    2495  0x00001a00
>     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
>       -      11    0.43    2523    2495  0x00000000
>       0       3    0.11    2631    2495  0x00000c00
>       1       7    0.27    2524    2495  0x00000800
>       2      18    0.72    2527    2495  0x00001a00
>       3      15    0.61    2501    2495  0x00001a00

Very Interesting.

I would still like to get a trace sample to post process.
Copied from a previous e-mail:

On an otherwise idle system, do:

# perf record -a --event=power:pstate_sample sleep 300

If pressed for time, your sleep time can be less than 5 minutes,
but try to get at least 100 seconds.

The resulting perf.data file will be too big to include as an
on-list attachment, but send it (or them) to me off-list for
post processing, and I'll report back.

... Doug

[toc] | [prev] | [next] | [standalone]

#1368383 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

From	"Doug Smythies" <dsmythies@telus.net>
Date	2016-03-31 17:20 +0200
Subject	RE: [intel-pstate driver regression] processor frequency very high even if in idle
Message-ID	<riMy6-71p-1@gated-at.bofh.it>
In reply to	#1368366

On 2016.03.31 07:40 Doug Smythies wrote:
> On 2016.03.31 02:24 Jörg Otte wrote:

>>
>> jojo@fichte:/sys/devices/system/cpu/cpufreq/policy0$ cat scaling_governor
>> powersave
>> 
>> turbostat -i 1 --msr=0x199
>> CPUID(7): No-SGX

... [cut]...

> Very Interesting.
>
> I would still like to get a trace sample to post process.
> Copied from a previous e-mail:
>
> On an otherwise idle system, do:
>
> # perf record -a --event=power:pstate_sample sleep 300
>
> If pressed for time, your sleep time can be less than 5 minutes,
> but try to get at least 100 seconds.
>
> The resulting perf.data file will be too big to include as an
> on-list attachment, but send it (or them) to me off-list for
> post processing, and I'll report back.

Never mind. I had not seen some of the e-mails, in particular
the one where Rafael had figured out the issue.

... Doug

[toc] | [prev] | [next] | [standalone]

#1368399

From	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date	2016-03-31 17:20 +0200
Message-ID	<riMy7-71p-37@gated-at.bofh.it>
In reply to	#1368366

On Thu, 2016-03-31 at 07:39 -0700, Doug Smythies wrote:
> On 2016.03.31 02:24 Jörg Otte wrote:

Hi Jörg,

Can you send me your kernel config file?

Thanks,
Srinivas
> 
> > jojo@fichte:/sys/devices/system/cpu/cpufreq/policy0$ cat
> > scaling_governor
> > powersave
> > 
> > turbostat -i 1 --msr=0x199
> > CPUID(7): No-SGX
> >     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
> >       -      45    1.74    2590    2496  0x00000000
> >       0      45    1.76    2565    2498  0x00000a00
> >       1      72    2.84    2548    2496  0x00000800
> >       2      30    1.11    2661    2496  0x00001a00
> >       3      33    1.23    2661    2495  0x00001a00
> >     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
> >       -       9    0.35    2525    2495  0x00000000
> >       0       1    0.04    2735    2495  0x00000800
> >       1       1    0.05    2501    2495  0x00000800
> >       2      17    0.65    2540    2495  0x00001a00
> >       3      16    0.64    2501    2495  0x00001a00
> >     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
> >       -      11    0.43    2523    2495  0x00000000
> >       0       3    0.11    2631    2495  0x00000c00
> >       1       7    0.27    2524    2495  0x00000800
> >       2      18    0.72    2527    2495  0x00001a00
> >       3      15    0.61    2501    2495  0x00001a00
> 
> Very Interesting.
> 
> I would still like to get a trace sample to post process.
> Copied from a previous e-mail:
> 
> On an otherwise idle system, do:
> 
> # perf record -a --event=power:pstate_sample sleep 300
> 
> If pressed for time, your sleep time can be less than 5 minutes,
> but try to get at least 100 seconds.
> 
> The resulting perf.data file will be too big to include as an
> on-list attachment, but send it (or them) to me off-list for
> post processing, and I'll report back.
> 
> ... Doug
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [next] | [standalone]

#1369060 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

From	"Doug Smythies" <dsmythies@telus.net>
Date	2016-04-01 09:30 +0200
Subject	RE: [intel-pstate driver regression] processor frequency very high even if in idle
Message-ID	<rj1GO-10N-11@gated-at.bofh.it>
In reply to	#1368065

On 2016.03.31 02:24 Jörg Otte wrote:
> 2016-03-30 22:26 GMT+02:00 Srinivas Pandruvada wrote:
>> On Wed, 2016-03-30 at 22:12 +0200, Rafael J. Wysocki wrote:
>>> On Wed, Mar 30, 2016 at 8:58 PM, Srinivas Pandruvada wrote:
>>>> On Wed, 2016-03-30 at 11:50 -0700, Doug Smythies wrote:

... [cut]...

>>>>>> Distro: Ubuntu 14.04.4 LTS
>>>>>> Note that with Ubuntu 14.04, I had issues where my CPU
>>>>>> would lock at pstate 24 (not always 24, but usually),
>>>>>> regardless of load.
>>>>>> However, it was always after an S3 suspend, occurred 100%
>>>>>> of the time, and was independent of intel_pstate or
>>>>>> acpi-cpufreq CPU frequency scaling drivers.
>>>>>>
>>>>>> Since changing my test server to Ubuntu server edition 16.04
>>>>>> (development version), I have not had those issues. While I have
>>>>>> no proof, I have assumed the issue elimination was somehow
>>>>>> related
>>>>>> to the change to systemd.
>>>>>>
>>>>>> It might be worth observing both what the intel_pstate is asking
>>>>>> for and what the processor is actually doing.
>>>> If Jörg runs with
>>>>
>> turbostat -i 1 --msr=0x199
>>
>> We can tell whether if we requested or the same problem you had.

Yes, it proves that pstate was requested, but it does not disprove that
the processor is in the locked up state.

...[cut]...

> jojo@fichte:/sys/devices/system/cpu/cpufreq/policy0$ cat scaling_governor
> powersave

> turbostat -i 1 --msr=0x199
> CPUID(7): No-SGX
>     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
>       -      45    1.74    2590    2496  0x00000000
>       0      45    1.76    2565    2498  0x00000a00
>       1      72    2.84    2548    2496  0x00000800
>       2      30    1.11    2661    2496  0x00001a00
>       3      33    1.23    2661    2495  0x00001a00
>     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
>       -       9    0.35    2525    2495  0x00000000
>       0       1    0.04    2735    2495  0x00000800
>       1       1    0.05    2501    2495  0x00000800
>       2      17    0.65    2540    2495  0x00001a00
>       3      16    0.64    2501    2495  0x00001a00
>     CPU Avg_MHz   Busy% Bzy_MHz TSC_MHz   MSR 0x199
>       -      11    0.43    2523    2495  0x00000000
>       0       3    0.11    2631    2495  0x00000c00
>       1       7    0.27    2524    2495  0x00000800
>       2      18    0.72    2527    2495  0x00001a00
>       3      15    0.61    2501    2495  0x00001a00

While there are other scenarios that would explain the
data, it is consistent with the processor locked pstate
scenario.

The suggestion is to limit what the intel_pstate driver will ask
for, and observe what is being given.

Example (using my computer, which is working fine):

1.) What is the minimum?

$ cat /sys/devices/system/cpu/intel_pstate/min_perf_pct
42

2.) Set the maximum the same as the minimum?

$ sudo su
root@s15:/home/doug/temp#
root@s15:/home/doug/temp# echo "42" > /sys/devices/system/cpu/intel_pstate/max_perf_pct

3.) check it:

root@s15:/home/doug/temp# cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
42

3.) Observe what is being asked for and given:

root@s15:/home/doug/temp# modprobe msr
root@s15:/home/doug/temp# rdmsr --bitfield 15:8 -d -a 0x198
16
16
16
16
16
16
16
16
root@s15:/home/doug/temp# rdmsr --bitfield 15:8 -d -a 0x199
16
16
16
16
16
16
16
16

Jörg: As Srinivas mentioned, your kernel configuration is very
odd. You mentioned you are using Ubuntu 14.04.4. Could you try
the Ubuntu mainline kernel 4.6-rc1? You can get it here:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc1-wily/

The reason I have been asking for trace data via a different
method than Rafael and Srinivas, is because I use a set
of post processing tools, originally created by the 
original intel_pstate driver maintainer.

... Doug

[toc] | [prev] | [next] | [standalone]

#1367520 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

From	"Doug Smythies" <dsmythies@telus.net>
Date	2016-03-30 21:00 +0200
Subject	RE: [intel-pstate driver regression] processor frequency very high even if in idle
Message-ID	<ritvs-1a3-9@gated-at.bofh.it>
In reply to	#1367328

On 2016.03.30 08:52 Jörg Otte wrote:
> 2016-03-30 17:33 GMT+02:00 Pandruvada, Srinivas <srinivas.pandruvada@intel.com>:
>> On Wed, 2016-03-30 at 13:05 +0200, Rafael J. Wysocki wrote:
>>> On Wed, Mar 30, 2016 at 12:17 PM, Jörg Otte <jrg.otte@gmail.com>

>>>>>> Now in v4.6-rc1 the characteristic has dramatically changed.
>>>>>> If in idle the processor frequency is more or less a few
>>>>>> MHz around 2500Mhz.
>>>>>> I currently use acpi_cpufreq which works as usual.
>>>>>> Processor: Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
>>>>>> (family: 0x6, model: 0x3c, stepping: 0x3)

>> I want to reproduce this if I can. Can you give us info about your
>> setup (Linux distribution, laptop model etc.)?

I would like to try to reproduce the issue also.

> Distro: Ubuntu 14.04.4 LTS

Note that with Ubuntu 14.04, I had issues where my CPU
would lock at pstate 24 (not always 24, but usually),
regardless of load.
However, it was always after an S3 suspend, occurred 100%
of the time, and was independent of intel_pstate or
acpi-cpufreq CPU frequency scaling drivers.

Since changing my test server to Ubuntu server edition 16.04
(development version), I have not had those issues. While I have
no proof, I have assumed the issue elimination was somehow related
to the change to systemd.

It might be worth observing both what the intel_pstate is asking for
and what the processor is actually doing.

What is being asked for:
# rdmsr --bitfield 15:8 -d -a 0x199

What is being given:
# rdmsr --bitfield 15:8 -d -a 0x198

An old problematic example from an idle system (mine)
Note, my minimum pstate is 16:

What was being given:
# rdmsr --bitfield 15:8 -d -a 0x198
24
24
24
24
24
24
24
24

What was being asked for:
# rdmsr --bitfield 15:8 -d -a 0x199
16
16
16
16
16
16
16
16

To gain further insight, it might also be worth acquiring
some trace data. On an otherwise idle system, do:

# perf record -a --event=power:pstate_sample sleep 300

If pressed for time, your sleep time can be less than 5 minutes,
but try to get at least 100 seconds.

The resulting perf.data file will be too big to include as an
on-list attachment, but send it (or them) to me off-list for
post processing, and I'll report back.

... Doug

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

Re: [intel-pstate driver regression] processor frequency very high even if in idle

Contents

#1369517 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

#1369524

#1369565

#1369660 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

#1369668

#1369580

#1369422 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

#1369482

#1369498

#1367308

#1367328

#1367519

#1367577

#1367597

#1368065

#1368366 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

#1368383 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

#1368399

#1369060 — RE: [intel-pstate driver regression] processor frequency very high even if in idle

#1367520 — RE: [intel-pstate driver regression] processor frequency very high even if in idle