Displaying 8 results from an estimated 8 matches for "cpufreq_cpu_polici".
Did you mean:
cpufreq_cpu_policy
2011 Oct 20
0
[PATCH 07/12] cpufreq: allocate CPU masks dynamically
struct cpufreq_policy, including a cpumask_t member, gets copied in
cpufreq_limit_change(), cpufreq_add_cpu(), set_cpufreq_gov(), and
set_cpufreq_para(). Make the member a cpumask_var_t, thus reducing the
amount of data needing copying (particularly with large NR_CPUS).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- 2011-09-20.orig/xen/arch/x86/acpi/cpufreq/cpufreq.c 2011-10-12
2011 Oct 14
1
[PATCH] cpufreq: error path fixes
This fixes an actual bug (failure to exit from a function after an
allocation failure), an inconsistency (not removing the cpufreq_dom
list member upon failure), and a latent bug (not clearing the current
governor upon governor initialization failure when there was no old
one; latent because the only current code path leading to this
situation frees the policy upon failure and hence the governor
2008 Sep 19
8
[PATCH] x86: add hypercall to query current underlying pCPU''s frequency
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Index: 2008-09-19/xen/arch/x86/platform_hypercall.c
===================================================================
--- 2008-09-19.orig/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:02.000000000 +0200
+++ 2008-09-19/xen/arch/x86/platform_hypercall.c 2008-09-19 14:12:56.000000000 +0200
@@ -21,7 +21,7 @@
#include <xen/acpi.h>
2013 Jun 20
3
[PATCH V2 1/2] cpufreq, xenpm: fix cpufreq and xenpm mismatch
Currently cpufreq and xenpm are out of sync. Fix cpufreq reporting of
if turbo mode is enabled or not. Fix xenpm to not decode for tristate,
but a boolean.
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
---
tools/misc/xenpm.c | 14 +++-----------
xen/drivers/cpufreq/utility.c | 2 +-
2 files changed, 4 insertions(+), 12 deletions(-)
diff --git a/tools/misc/xenpm.c
2011 Nov 15
0
[PATCH] xen: avoid crash enabling turbo mode
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1321356497 0
# Node ID 3cfb8f2c4ce898414279d7162206be812584bd5b
# Parent 955a6c07dc5e9c55316d1678b2b7cc4313f4fd57
xen: avoid crash enabling turbo mode
On a system which has not had P-state information pushed down into the
hypervisor running "xenpm enable-turbo-mode" will reliably crash the host.
(XEN) PM
2010 Jul 06
0
[PATCH] x86/cpufreq: check array index before use
... rather than after.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
--- 2010-06-15.orig/xen/arch/x86/acpi/cpufreq/cpufreq.c 2010-07-06 16:08:59.000000000 +0200
+++ 2010-06-15/xen/arch/x86/acpi/cpufreq/cpufreq.c 2010-07-06 16:11:48.000000000 +0200
@@ -210,9 +210,11 @@ static u32 get_cur_val(cpumask_t mask)
if (!cpu_isset(cpu, mask))
cpu = first_cpu(mask);
- policy =
2013 Jun 19
8
[PATCH 1/2] cpufreq, powernow: enable/disable core performance boost for all cpus in policy
Currently, enable/disable turbo mode on AMD is broken:
$ xenpm enable-turbo-mode 0 <-- works and proper CPU MSR bit is set
$ xenpm enable-turbo-mode 1 <-- silently broken, MSR bit not set
Since ->turbo is per policy, when user requests to enable/disable
turbo mode, we need to set the bit in all of the ->cpus that this
policy affects.
---
xen/arch/x86/acpi/cpufreq/powernow.c | 2
2008 Sep 17
5
c/s 18470
This changeset reverts two previous corrections, for reasons that escape
me.
First, the domain map is again being confined to NR_CPUS, which I had
submitted a patch to fix recently (yes, I realize the code has a TODO in
there, but those really get forgotten about far too often).
Second, the platform hypercall was reverted back to require all
information to be passed to Xen in one chunk, whereas