On 11/30/2014 06:32 PM, Ethan Zhao wrote:
Oracle Sun X86 servers have dynamic power capping capability that works via
ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
enabled.
Signed-off-by: Ethan Zhao
Signed-off-by: Dirk Brandewie
Tested-by: Linda Knippers
In
On 11/24/2014 08:59 PM, Ethan Zhao wrote:
Oracle Sun X86 servers have dynamic power capping capability that works via
ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
enabled.
How about this patch? only compile tested.
diff --git a/drivers/cpufreq/intel_pstate.c b
On 11/24/2014 08:59 PM, Ethan Zhao wrote:
To force loading on Oracle Sun X86 servers, provide one kernel command line
parameter
intel_pstate = onora
For those who be aware of the risk doing so.
Signed-off-by: Ethan Zhao
---
v2: change to hardware vendor specific naming parameter.
Docu
On 11/19/2014 12:22 PM, Linda Knippers wrote:
On 11/18/2014 3:37 AM, Ethan Zhao wrote:
Oracle Sun X86 servers have dynamic power capping capability that works via
ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
enabled.
Signed-off-by: Ethan Zhao
---
drivers/cpuf
On 11/18/2014 12:37 AM, Ethan Zhao wrote:
Oracle Sun X86 servers have dynamic power capping capability that works via
ACPI _PPC method etc, so skip loading this driver if Sun server has ACPI _PPC
enabled.
Signed-off-by: Ethan Zhao
---
drivers/cpufreq/intel_pstate.c | 20
From: Dirk Brandewie
Add support of Hardware Managed Performance States (HWP) described in Volume 3
section 14.4 of the SDM.
One bit CPUID.06H:EAX[bit 7] expresses the presence of the HWP feature on
the processor. The remaining bits CPUID.06H:EAX[bit 8-11] denote the
presense of various HWP
From: Dirk Brandewie
Add support of Hardware Managed Performance States (HWP) described in Volume 3
section 14.4 of the SDM.
With HWP enbaled intel_pstate will no longer be responsible for selecting P
states for the processor. intel_pstate will continue to register to
the cpufreq core as the
From: Dirk Brandewie
This patch set adds support for HWP. When HWP is enabled the CPU will
do P state autonomously and intel_pstate simply provides an interface
to forward user preferences to the CPU while maintaining the
interfaces required by the cpufreq core.
Dirk Brandewie (2):
x86: Add
On 10/30/2014 02:18 PM, Rafael J. Wysocki wrote:
On Thursday, October 16, 2014 07:37:11 AM James Geboski wrote:
The intel_pstate driver only supports the performance and the powersave
governors. With the performance governor ensuring the highest possible
performance settings, userspace tools fai
also max value for max_perf_pct.
Signed-off-by: Pali Rohár
Acked-by: Dirk Brandewie
Cc: sta...@vger.kernel.org
---
drivers/cpufreq/intel_pstate.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 0668b38..7547ab5 10
On 09/10/2014 06:04 PM, Sameer Nanda wrote:
On Wed, Sep 10, 2014 at 5:04 PM, Rafael J. Wysocki wrote:
On Wednesday, September 10, 2014 04:39:05 PM Anup Chenthamarakshan wrote:
On Thu, Sep 11, 2014 at 12:49:48AM +0200, Rafael J. Wysocki wrote:
On Wednesday, September 10, 2014 03:15:08 PM Anup
On 09/10/2014 09:11 AM, Ashwin Chaugule wrote:
On 10 September 2014 11:44, Dirk Brandewie wrote:
Hi Ashwin,
Hi Dirk,
I think the CPPC based driver should be a separate driver.
We made the conscious decision to not use any of the ACPI mechanisms
to enumerate or control P state selection
On 09/09/2014 04:22 PM, Anup Chenthamarakshan wrote:
On Tue, Sep 09, 2014 at 08:15:13AM -0700, Dirk Brandewie wrote:
On 09/08/2014 05:10 PM, Anup Chenthamarakshan wrote:
Exported stats appear in
/devices/system/cpu/intel_pstate/time_in_state as follows:
## CPU 0
40 3647
50 24342
Hi Ashwin,
I think the CPPC based driver should be a separate driver.
We made the conscious decision to not use any of the ACPI mechanisms
to enumerate or control P state selection. Experience over the years
has shown that the quality/accuracy of the BIOS/ACPI implementations
vary widely across
On 09/08/2014 05:10 PM, Anup Chenthamarakshan wrote:
> Exported stats appear in
> /devices/system/cpu/intel_pstate/time_in_state as follows:
>
> ## CPU 0
> 40 3647
> 50 24342
> 60 144150
> 70 202469
> ## CPU 1
> 40 4813
> 50 22628
> 60 149564
> 70 211885
> 80 17
Signed-off-by: Andi Kleen
Acked-by: Dirk Brandewie
---
drivers/cpufreq/intel_pstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index c5eac94..17be734 100644
--- a/drivers/cpufreq/intel_pstate.
On 08/22/2014 03:19 AM, Viresh Kumar wrote:
On 22 August 2014 15:35, Mika Westerberg
wrote:
This is pretty much the same as Intel Baytrail, only the CPU ID is
different. Add the new ID to the supported CPU list.
Signed-off-by: Mika Westerberg
Cc: Dirk Brandewie
Dirk might be away on
On 07/15/2014 03:47 PM, Saravana Kannan wrote:
The CPUfreq core moves the cpufreq policy ownership between CPUs when CPUs
within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When moving
policy ownership between CPUs, it also moves the cpufreq sysfs directory
between CPUs and also fixes
On 06/12/2014 01:03 PM, Rafael J. Wysocki wrote:
On Thursday, June 12, 2014 05:35:59 PM Stratos Karafotis wrote:
On 12/06/2014 12:15 πμ, Doug Smythies wrote:
-Original Message-
From: Stratos Karafotis [mailto:strat...@semaphore.gr]
Sent: June-11-2014 13:20
To: Doug Smythies
Cc: linux.
On 06/10/2014 08:31 AM, Rafael J. Wysocki wrote:
On Tuesday, June 10, 2014 08:12:48 AM Dirk Brandewie wrote:
On 06/09/2014 02:01 PM, Stratos Karafotis wrote:
Remove unnecessary blank lines.
Remove unnecessary parentheses.
Remove unnecessary braces.
Put the code in one line where possible.
Add
On 06/09/2014 02:01 PM, Stratos Karafotis wrote:
Since we never remove sysfs entry, we can make the intel_pstate_kobject
local.
Signed-off-by: Stratos Karafotis
Acked-by: Dirk Brandewie
drivers/cpufreq/intel_pstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
), GFP_KERNEL);
if (!all_cpu_data[cpunum])
return -ENOMEM;
Acked-by: Viresh Kumar
Acked-by: Dirk Brandewie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On 06/10/2014 07:51 AM, Stratos Karafotis wrote:
On 10/06/2014 08:27 πμ, Viresh Kumar wrote:
On 10 June 2014 02:30, Stratos Karafotis wrote:
Simplify the code by removing the inline functions
pstate_increase and pstate_decrease and use directly the
intel_pstate_set_pstate.
Doesn't apply wit
On 06/10/2014 09:21 AM, Stratos Karafotis wrote:
> On 10/06/2014 06:47 μμ, Dirk Brandewie wrote:
>> On 06/09/2014 02:00 PM, Stratos Karafotis wrote:
>>> Add stats file in debugfs under driver's parent directory
>>> (pstate_snb) which counts the time in nsecs p
On 06/09/2014 02:00 PM, Stratos Karafotis wrote:
Store busy_scaled value to avoid to duplicate call of
intel_pstate_get_scaled_busy on every sampling interval.
The second call *only* happens if the tracepoint is being used otherwise
the whole function call to trace_pstate_sample() is a noop.
On 06/09/2014 02:00 PM, Stratos Karafotis wrote:
Add stats file in debugfs under driver's parent directory
(pstate_snb) which counts the time in nsecs per requested
P state and the number of times the specific state
was requested.
The file presents the statistics per logical CPU in the
following
On 06/09/2014 02:01 PM, Stratos Karafotis wrote:
Remove unnecessary blank lines.
Remove unnecessary parentheses.
Remove unnecessary braces.
Put the code in one line where possible.
Add blank lines after variable declarations.
Alignment to open parenthesis.
I don't have an issue with this patch
On 06/09/2014 03:02 PM, Martin Steigerwald wrote:
Am Montag, 9. Juni 2014, 23:41:40 schrieb Martin Steigerwald:
Am Montag, 9. Juni 2014, 23:33:43 schrieb Martin Steigerwald:
Hi!
Added linux-pm to Cc. Also reboots seems to fix up the condition:
merkaba:~> grep . /sys/devices/system/cpu/cpu[0-3
Hi Martin,
Can you send the output of:
turbostat sleep 10
and
for i in 0 1 2 3; do rdmsr -p $i -u -f15:8 0x198; done
For the normal and bad case please.
--Dirk
On 06/09/2014 02:33 PM, Martin Steigerwald wrote:
Hi!
Added linux-pm to Cc. Also reboots seems to fix up the condition:
mer
governors.
Cc: Viresh Kumar
Cc: Dirk Brandewie
Cc: Randy Dunlap
Cc: Russell King
Cc: Jesper Nilsson
Cc: Viresh Kumar
Cc: "David S. Miller"
Cc: Ramkumar Ramachandra
Cc: "Rafael J. Wysocki"
Cc: linux-...@vger.kernel.org
Signed-off-by: Prarit Bhargava
Acked-by: Dirk Bra
On 06/04/2014 11:52 PM, Peter Zijlstra wrote:
On Wed, Jun 04, 2014 at 11:56:55PM +0200, Rafael J. Wysocki wrote:
On Wednesday, June 04, 2014 07:27:12 PM Peter Zijlstra wrote:
Well, we eventually want to go there I think. Although we still needed
to come up with something for Intel, because I'
On 05/30/2014 01:07 PM, Tim Chen wrote:
On Fri, 2014-05-30 at 12:38 -0700, Dirk Brandewie wrote:
Dirk,
Thanks for checking things out.
I tested on a Haswell system, and I see that the frequency
can dip below the max even when I set the min_perf_pct to 100.
Let me know if you want to log on
On 05/30/2014 12:32 PM, Tim Chen wrote:
On Fri, 2014-05-30 at 11:45 -0700, Dirk Brandewie wrote:
With turbostat from rc7.
[root@echolake turbostat]# ./turbostat
Core CPU Avg_MHz %Busy Bzy_MHz TSC_MHz SMI CPU%c1 CPU%c3
CPU%c6 CPU%c7 CoreTmp PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6
On 05/30/2014 10:56 AM, Tim Chen wrote:
> On Thu, 2014-05-29 at 21:16 -0400, Dave Jones wrote:
>> On Thu, May 29, 2014 at 06:07:16PM -0700, Tim Chen wrote:
>> > On Thu, 2014-05-29 at 19:54 -0400, George Spelvin wrote:
>> > > Sorry for the delay; my Ivy Bridge test machine isn't in my
>> > > o
On 05/20/2014 11:12 AM, Stratos Karafotis wrote:
Although, a value is assigned to member name of struct cpudata,
it is never used.
We can safely remove it.
Signed-off-by: Stratos Karafotis
Acked-by: Dirk Brandewie
---
drivers/cpufreq/intel_pstate.c | 4
1 file changed, 4 deletions
On 05/12/2014 05:16 AM, Rafael J. Wysocki wrote:
On Monday, May 12, 2014 05:27:25 AM Stratos Karafotis wrote:
Hi,
[cut]
With this patch, my CPU (Core i7-3770 @ 3.90GHz) seems to never use lowest
frequencies. Even on an idle system I get always ~2GHz. Normally,
on an idle system it used to
On 05/08/2014 01:30 PM, Rafael J. Wysocki wrote:
On Thursday, May 08, 2014 12:57:22 PM dirk.brande...@gmail.com wrote:
From: Dirk Brandewie
Patches 1-4 are bugfixes. Patch 4 specifically removes the wreckage
caused by C0 tracking change.
I would appreciate sending such stuff before the
On 05/05/2014 04:57 PM, Stratos Karafotis wrote:
> Currently the driver calculates the next pstate proportional to
> core_busy factor, scaled by the ratio max_pstate / current_pstate.
>
> Using the scaled load (core_busy) to calculate the next pstate
> is not always correct, because there are case
From: Dirk Brandewie
Setting the P state of the core to max at init time is a hold over
from early implementation of intel_pstate where intel_pstate disabled
cpufreq and loaded VERY early in the boot sequence. This was to
ensure that intel_pstate did not affect boot time. This in not needed
now
From: Dirk Brandewie
Commit fcb6a15c intel_pstate: Take core C0 time into account for core busy
introduced a regression referenced below. The issue with "lockup"
after suspend that this commit was addressing is now dealt with in the
suspend path.
References:
https://bugzilla.
From: Dirk Brandewie
Patches 1-4 are bugfixes. Patch 4 specifically removes the wreckage
caused by C0 tracking change.
Patch 5 Adds new CPU IDs for the Broadwell processors.
Dirk Brandewie (5):
intel_pstate: Set turbo VID for Baytrail
intel_pstate: remove setting P state to MAX on init
From: Dirk Brandewie
Add support the Broadwell processors.
Signed-off-by: Dirk Brandewie
---
drivers/cpufreq/intel_pstate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 4c26faf..6ef6f7f 100644
--- a/drivers
From: Dirk Brandewie
Change the FP_ROUNDUP macro to add 0.5 in fixed point representation
instead of 1.0
Signed-off-by: Dirk Brandewie
---
drivers/cpufreq/intel_pstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq
On 05/06/2014 10:40 PM, Viresh Kumar wrote:
Cc'ing Dirk who is taking care of intel-pstate driver.
Thanks Viresh I had seen this thread.
I am looking into it
--Dirk
On 6 May 2014 22:05, Johan Hovold wrote:
After updating my main system from v3.13 to v3.14.2, I found that the
git bash-comp
On 05/01/2014 04:18 PM, Rafael J. Wysocki wrote:
On Thursday, May 01, 2014 02:30:42 PM Dirk Brandewie wrote:
On 05/01/2014 02:00 PM, Stratos Karafotis wrote:
Currently the driver calculates the next pstate proportional to
core_busy factor, scaled by the ratio max_pstate / current_pstate
On 05/01/2014 02:00 PM, Stratos Karafotis wrote:
Currently the driver calculates the next pstate proportional to
core_busy factor, scaled by the ratio max_pstate / current_pstate.
Using the scaled load (core_busy) to calculate the next pstate
is not always correct, because there are cases that t
our power lab and see if we can reproduce
your results in other workloads.
And I'm waiting for the intel_pstate developer Dirk Brandewie to comment.
Sorry I just returned from dealing with a family emergency and am digging
out of my inbox.
I will run this patch through some tests.
Tha
MPLE_COUNT macro.
While at it, reformat the first line in this function.
Signed-off-by: Stratos Karafotis
Acked-by: Dirk Brandewie
---
drivers/cpufreq/intel_pstate.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drive
From: Dirk Brandewie
Ensure that no timer callback is running since we are about to free
the timer structure. We cannot guarantee that the call back is called
on the CPU where the timer is running.
Reported-by: Thomas Gleixner
Signed-off-by: Dirk Brandewie
Cc: Thomas Gleixner
Cc: "Raf
Hi Thomas,
On 03/23/2014 06:56 PM, Rafael J. Wysocki wrote:
On Sunday, March 23, 2014 03:09:32 PM Thomas Gleixner wrote:
We are about to free the data structure. Make sure no timer callback
is running. I might be paranoid, but the ->exit callback can be
invoked from so many places, that it is no
On 03/19/2014 08:28 PM, Rafael J. Wysocki wrote:
On Wednesday, March 19, 2014 11:31:31 PM Rafael J. Wysocki wrote:
On Wednesday, March 19, 2014 08:45:53 AM dirk.brande...@gmail.com wrote:
From: Dirk Brandewie
This callback allows the driver to do clean up before the CPU is
completely down
On 03/18/2014 10:20 PM, Viresh Kumar wrote:
On 19 March 2014 01:14, Dirk Brandewie wrote:
There was no problem per se. In stop() all I really needed to do is stop
the
timer and set the P state to MIN.
At init time I need to allocate memory and start timer. If stopping the
timer
and
From: Dirk Brandewie
This callback allows the driver to do clean up before the CPU is
completely down and its state cannot be modified. This is used
by the intel_pstate driver to reduce the requested P state prior to
the core going away. This is required because the requested P state
of the
From: Dirk Brandewie
Change to use ->exit_prepare() callback to do clean up during CPU
hotplug. The requested P state for an offline core will be used by the
hardware coordination function to select the package P state. If the
core is under load when it is offlined it will fix the packag
From: Dirk Brandewie
Changes:
v3->v4
Change to only call ->stop() callback for drivers exposing the
->set_policy() callback.
v2->v3
Changed the calling of the ->stop() callback to be conditional on the
core being the last core controlled by a given policy.
v1->2
Chang
On 03/18/2014 11:52 AM, Srivatsa S. Bhat wrote:
On 03/18/2014 08:31 PM, Dirk Brandewie wrote:
On 03/17/2014 10:44 PM, Viresh Kumar wrote:
On Sat, Mar 15, 2014 at 2:33 AM, wrote:
+
static int intel_pstate_cpu_init(struct cpufreq_policy *policy)
{
struct cpudata *cpu
On 03/18/2014 12:08 PM, Srivatsa S. Bhat wrote:
On 03/18/2014 10:52 PM, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie
I don't mean to nitpick, but generally its easier to deal with
patchsets if you post the subsequent versions in fresh email threads.
Otherwise it can get
From: Dirk Brandewie
Change to use ->exit_prepare() callback to do clean up during CPU
hotplug. The requested P state for an offline core will be used by the
hardware coordination function to select the package P state. If the
core is under load when it is offlined it will fix the packag
From: Dirk Brandewie
Changes:
v2->v3
Changed the calling of the ->stop() callback to be conditional on the
core being the last core controlled by a given policy.
v1->2
Change name of callback function added to cpufreq_driver interface.
Some drivers (intel_pstate) need to modify s
From: Dirk Brandewie
This callback allows the driver to do clean up before the CPU is
completely down and its state cannot be modified. This is used
by the intel_pstate driver to reduce the requested P state prior to
the core going away. This is required because the requested P state
of the
On 03/17/2014 10:44 PM, Viresh Kumar wrote:
On Sat, Mar 15, 2014 at 2:33 AM, wrote:
+
static int intel_pstate_cpu_init(struct cpufreq_policy *policy)
{
struct cpudata *cpu;
@@ -818,7 +824,7 @@ static struct cpufreq_driver intel_pstate_driver = {
.setpolicy = intel_ps
From: Dirk Brandewie
Some drivers (intel_pstate) need to modify state on a core before it
is completely offline. The ->exit() callback is executed during the
CPU_POST_DEAD phase of the cpu offline process which is too late to
change the state of the core.
Patch 1 adds an optional callb
From: Dirk Brandewie
Change to use ->stop() callback to do clean up during CPU
hotplug. The requested P state for an offline core will be used by the
hardware coordination function to select the package P state. If the
core is under load when it is offlined it will fix the package P state
fl
From: Dirk Brandewie
This callback allows the driver to do clean up before the CPU is
completely down and its state cannot be modified. This is used
by the intel_pstate driver to reduce the requested P state prior to
the core going away. This is required because the requested P state
of the
On 03/14/2014 10:07 AM, Viresh Kumar wrote:
On 14 March 2014 20:40, Dirk Brandewie wrote:
Are you proposing adding cpufreq_generic_suspend() to the core I can not
find
it in the mainline code.
Its already there in linux-next. I am suggesting to reuse that
infrastructure with
some necessary
On 03/13/2014 09:59 PM, Viresh Kumar wrote:
On Thu, Mar 13, 2014 at 11:06 PM, wrote:
From: Dirk Brandewie
Some drivers (intel_pstate) need to modify state on a core before it
is completely offline. The ->exit() callback is executed during the
CPU_POST_DEAD phase of the cpu offline proc
From: Dirk Brandewie
Some drivers (intel_pstate) need to modify state on a core before it
is completely offline. The ->exit() callback is executed during the
CPU_POST_DEAD phase of the cpu offline process which is too late to
change the state of the core.
Patch 1 adds an optional callb
From: Dirk Brandewie
This callback allows the driver to do clean up before the CPU is
completely down and its state cannot be modified. This is used
by the intel_pstate driver to reduce the requested P state prior to
the core going away. This is required because the requested P state
of the
From: Dirk Brandewie
Change to use ->exit_prepare() callback to do clean up during CPU
hotplug. The requested P state for an offline core will be used by the
hardware coordination function to select the package P state. If the
core is under load when it is offlined it will fix the packag
On 03/11/2014 12:29 PM, Rafael J. Wysocki wrote:
On Tuesday, March 11, 2014 10:13:00 AM Dirk Brandewie wrote:
On 03/11/2014 10:03 AM, Soren Brinkmann wrote:
From: Joe Perches
- Add missing newlines
- Coalesce format fragments
- Convert printks to pr_
- Align arguments
This
On 03/11/2014 10:03 AM, Soren Brinkmann wrote:
From: Joe Perches
- Add missing newlines
- Coalesce format fragments
- Convert printks to pr_
- Align arguments
This introduces a bunch of lines over 80 charaters long.
Original-patch-by: Sören Brinkmann
Signed-off-by: Joe Perches
Ac
On 02/26/2014 08:41 AM, Josh Triplett wrote:
On Wed, Feb 26, 2014 at 10:08:26PM +0530, Rashika Kheria wrote:
Mark function as static in cpufreq.c because it is not
used outside this file.
This eliminates the following warning in cpufreq.c:
drivers/cpufreq/cpufreq.c:355:9: warning: no previous p
From: Dirk Brandewie
Commit fcb6a15c2e Take core C0 time into account for core busy calculation.
Introduced a regression on some processor SKUs supported by
intel_pstate. This was caused by the truncation caused by using
integer math to calculate core busy and C0 percentages.
On a i7-4770K
On 02/24/2014 02:37 PM, Greg KH wrote:
On Thu, Feb 20, 2014 at 10:10:46AM -0800, Greg KH wrote:
On Thu, Feb 20, 2014 at 06:56:24AM -0800, Dirk Brandewie wrote:
On 02/19/2014 04:51 PM, Greg KH wrote:
On Wed, Feb 19, 2014 at 04:35:37PM -0800, Greg KH wrote:
On Wed, Feb 19, 2014 at 04:03:40PM
On 02/20/2014 11:06 AM, Otto Meier wrote:
Am 20.02.2014 17:48, schrieb Dirk Brandewie:
On 02/20/2014 07:01 AM, Borislav Petkov wrote:
Add lists to CC.
On Thu, Feb 20, 2014 at 03:32:36PM +0100, Otto Meier wrote:
Hello,
My System which runs with older kernels up to 3.13.3
fine on my i3-4330
On 02/20/2014 07:01 AM, Borislav Petkov wrote:
Add lists to CC.
On Thu, Feb 20, 2014 at 03:32:36PM +0100, Otto Meier wrote:
Hello,
My System which runs with older kernels up to 3.13.3
fine on my i3-4330 with 3.5 Ghz and governor powersave.
and pstate driver.
With kernel 3.14-rc3 and Governor
On 02/19/2014 04:51 PM, Greg KH wrote:
On Wed, Feb 19, 2014 at 04:35:37PM -0800, Greg KH wrote:
On Wed, Feb 19, 2014 at 04:03:40PM -0800, Dirk Brandewie wrote:
On 02/19/2014 02:47 PM, Greg KH wrote:
Hi Dirk,
I've been having some huge slowdowns on my box building kernels, and I
took the
On 02/19/2014 02:47 PM, Greg KH wrote:
Hi Dirk,
I've been having some huge slowdowns on my box building kernels, and I
took the time to bisect it down to commit
fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4 (intel_pstate: Take core C0
time into account for core busy calculation). With that patch rev
From: Dirk Brandewie
LFM (max efficiency ratio) is the max frequency at minimum voltage
supported by the processor. Using LFM as the minimum P state
increases performmance without affecting power. By not using P states
below LFM we avoid using P states that are less power efficient.
Signed-off
On 02/18/2014 04:53 PM, Rafael J. Wysocki wrote:
On Tuesday, February 18, 2014 04:35:26 PM Dirk Brandewie wrote:
On 02/18/2014 04:43 PM, Rafael J. Wysocki wrote:
On Tuesday, February 18, 2014 04:24:02 PM Dirk Brandewie wrote:
On Tuesday, February 18, 2014, Rafael J. Wysocki wrote:
On
On 02/19/2014 04:52 AM, Stefan Lippers-Hollmann wrote:
Hi
On Tuesday 18 February 2014, Greg Kroah-Hartman wrote:
3.13-stable review patch. If anyone has any objections, please let me know.
--
From: Dirk Brandewie
commit fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4 upstream
On 02/19/2014 06:06 AM, Fengguang Wu wrote:
Hi Dirk,
FYI, we noticed the below changes on commit
1abc4b20b85b42e8573957e54b193385cf48b0d6
("cpufreq / intel_pstate: remove idle time and duration from sample and
calculations"):
This commit was a LONG time ago. How does this compare to the cu
On 02/18/2014 04:43 PM, Rafael J. Wysocki wrote:
On Tuesday, February 18, 2014 04:24:02 PM Dirk Brandewie wrote:
On Tuesday, February 18, 2014, Rafael J. Wysocki wrote:
On Tuesday, February 18, 2014 03:53:48 PM Dirk Brandewie wrote:
On 02/18/2014 02:27 PM, Rafael J. Wysocki wrote:
On
On 02/18/2014 02:27 PM, Rafael J. Wysocki wrote:
On Tuesday, February 18, 2014 12:29:54 PM Dirk Brandewie wrote:
Hi Rafael,
Hi,
On 02/12/2014 10:01 AM, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie
Based on v3.14-rc2
Patch 1 removes energy reporting the patch from Maurizio
Hi Rafael,
On 02/12/2014 10:01 AM, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie
Based on v3.14-rc2
Patch 1 removes energy reporting the patch from Maurizio Lambardi
intel_pstate: fix race condition in intel_pstate_init() can be dropped.
Any reason why patches 2-5 did not make
From: Dirk Brandewie
Remove unneeded sample buffers, intel_pstate operates on the most
recent sample only. This save some memory and make the code more
readable.
Signed-off-by: Dirk Brandewie
---
drivers/cpufreq/intel_pstate.c | 25 -
1 file changed, 12 insertions
From: Dirk Brandewie
commit d253d2a526 Improve accuracy by not truncating until final
result, changed internal variables of the PID to be fixed point
numbers. Update the pid_reset() to reflect this change.
Signed-off-by: Dirk Brandewie
---
drivers/cpufreq/intel_pstate.c | 2 +-
1 file changed
From: Dirk Brandewie
A documentation update exposed the existance of the turbo ratio
register. Update baytrail support to use the turbo range.
Signed-off-by: Dirk Brandewie
---
drivers/cpufreq/intel_pstate.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a
From: Dirk Brandewie
Remove the reporting of energy since it does not provide any useful
information about the state of the driver and will be a maintainance
headache going forward since the RAPL energy units register is not
architectural and subject to change between micro-architectures
Signed
From: Dirk Brandewie
Using LFM ratio provides better perf/watt vs min ratio.
Signed-off-by: Dirk Brandewie
---
drivers/cpufreq/intel_pstate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index b80c03d
From: Dirk Brandewie
Based on v3.14-rc2
Patch 1 removes energy reporting the patch from Maurizio Lambardi
intel_pstate: fix race condition in intel_pstate_init() can be dropped.
Patch 2-3 cleanups
Patch 4-5 Baytrail bug fixes
Dirk Brandewie (5):
intel_pstate: Remove energy reporting from
On 02/07/2014 04:33 AM, Fengguang Wu wrote:
Hi Dirk,
FYI, we notice dropped power and performance numbers on commit
fcb6a15c2e7e76d493e6f91ea889ab40e1c643a4 ("intel_pstate: Take core C0
time into account for core busy calculation").
v3.14-rc1 fcb6a15c2e7e76d493e6f91ea
---
/0x430
[2.750390] RSP
[2.751934] tsc: Refined TSC clocksource calibration: 3092.975 MHz
[2.760048] divide error: [#2] [2.760064] ---[ end trace
b87c91b37801378a ]---
[2.761931] Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Maurizio Lombardi
Acked-by
-state driver initializing." in dmesg for KVM.
commit 4279f36818bd3ac42f077de114b17eb27d81d482
Author: Dirk Brandewie
Date: Mon Jan 6 10:19:38 2014 -0800
intel_pstate: Add X86_FEATURE_APERFMPERF to cpu match parameters.
KVM environments do not support APERF/MPERF MSRs. intel
On 01/03/2014 02:06 PM, Paolo Bonzini wrote:
Il 03/01/2014 21:00, Dirk Brandewie ha scritto:
+case MSR_IA32_MPERF:
+case MSR_IA32_APERF:
OK I will spin the patch to only add MSR_PLATFORM_INFO.
These should never be accessed. A KVM VM will always have
CPUID[06H].ECX = 0, and the
On 01/03/2014 10:04 AM, Gleb Natapov wrote:
On Fri, Jan 03, 2014 at 09:30:28AM -0800, Dirk Brandewie wrote:
Hi All,
Sorry for being late to the party but I just got back from vacation.
There is something deeply wrong here. We should have never gotten to
intel_pstate_init_cpu(). The VM had
On 01/03/2014 04:09 AM, Rafael J. Wysocki wrote:
On Friday, January 03, 2014 05:01:13 PM Ramkumar Ramachandra wrote:
The Intel P-state driver is currently undocumented. Add some
documentation based on the cover-letter sent with the original series.
Cc: Dirk Brandewie
Dirk, what do you think
Hi All,
Sorry for being late to the party but I just got back from vacation.
There is something deeply wrong here. We should have never gotten to
intel_pstate_init_cpu(). The VM had to have returned value from the read
of the max pstate at driver init time and 0 when the CPU was being brought
Hi All,
I would like to see what is required to update intel_pstate in the stable
trees. Some of the patches do NOT meet the all the rules in
stable_kernel_rules.txt. v3.10.xx with intel_pstate is being used by multiple
projects at Intel that support the Baytrail and Haswell platforms. I assum
Hi Joakim,
Add the following patch to your v3.12 kernel and collect some data with the
command and send the resulting perf.data file:
perf record -a -c 1 -e power:pstate_sample sleep 10
TIA
--Dirk
commit b3dc2c2a106cea68e4c9c0f4747b15291113c4ae
Author: Dirk Brandewie
Date: Mon Dec 2 09
1 - 100 of 188 matches
Mail list logo
