31 Mar, 2011
1 commit
-
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi
24 Mar, 2011
1 commit
-
The cpufreq subsystem uses sysdev suspend and resume for
executing cpufreq_suspend() and cpufreq_resume(), respectively,
during system suspend, after interrupts have been switched off on the
boot CPU, and during system resume, while interrupts are still off on
the boot CPU. In both cases the other CPUs are off-line at the
relevant point (either they have been switched off via CPU hotplug
during suspend, or they haven't been switched on yet during resume).
For this reason, although it may seem that cpufreq_suspend() and
cpufreq_resume() are executed for all CPUs in the system, they are
only called for the boot CPU in fact, which is quite confusing.To remove the confusion and to prepare for elimiating sysdev
suspend and resume operations from the kernel enirely, convernt
cpufreq to using a struct syscore_ops object for the boot CPU
suspend and resume and rename the callbacks so that their names
reflect their purpose. In addition, put some explanatory remarks
into their kerneldoc comments.Signed-off-by: Rafael J. Wysocki
17 Mar, 2011
6 commits
-
None of the existing cpufreq drivers uses the second argument of
its .suspend() callback (which isn't useful anyway), so remove it.Signed-off-by: Rafael J. Wysocki
Signed-off-by: Dave Jones -
There cannot be any concurrent access to these through
different cpu sysfs files anymore, because these tunables
are now all global (not per cpu).I still have some doubts whether some of these locks
were needed at all. Anyway, let's get rid of them.Signed-off-by: Thomas Renninger
Signed-off-by: Dave Jones
CC: cpufreq@vger.kernel.org -
Marked deprecated for quite a whilte now...
Signed-off-by: Thomas Renninger
Signed-off-by: Dave Jones
CC: cpufreq@vger.kernel.org -
Marked deprecated for quite a while now...
Signed-off-by: Thomas Renninger
Signed-off-by: Dave Jones
CC: cpufreq@vger.kernel.org -
calculate ondemand delay after dbs_check_cpu call because it can
modify rate_mult valueuse freq_lo_jiffies value for the sub sample period of powersave_bias mode
Signed-off-by: Vincent Guittot
Signed-off-by: Dave Jones -
Signed-off-by: Joe Perches
Signed-off-by: Dave Jones
16 Mar, 2011
1 commit
-
* 'for-2.6.39' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: fix build failure introduced by s/freezeable/freezable/
workqueue: add system_freezeable_wq
rds/ib: use system_wq instead of rds_ib_fmr_wq
net/9p: replace p9_poll_task with a work
net/9p: use system_wq instead of p9_mux_wq
xfs: convert to alloc_workqueue()
reiserfs: make commit_wq use the default concurrency level
ocfs2: use system_wq instead of ocfs2_quota_wq
ext4: convert to alloc_workqueue()
scsi/scsi_tgt_lib: scsi_tgtd isn't used in memory reclaim path
scsi/be2iscsi,qla2xxx: convert to alloc_workqueue()
misc/iwmc3200top: use system_wq instead of dedicated workqueues
i2o: use alloc_workqueue() instead of create_workqueue()
acpi: kacpi*_wq don't need WQ_MEM_RECLAIM
fs/aio: aio_wq isn't used in memory reclaim path
input/tps6507x-ts: use system_wq instead of dedicated workqueue
cpufreq: use system_wq instead of dedicated workqueues
wireless/ipw2x00: use system_wq instead of dedicated workqueues
arm/omap: use system_wq in mailbox
workqueue: use WQ_MEM_RECLAIM instead of WQ_RESCUER
02 Mar, 2011
1 commit
-
cpufreq_register_driver sets cpufreq_driver to a structure owned (and
placed) in the caller's memory. If cpufreq policy fails in its ->init
function, sysdev_driver_register returns nonzero in
cpufreq_register_driver. Now, cpufreq_register_driver returns an error
without setting cpufreq_driver back to NULL.Usually cpufreq policy modules are unloaded because they propagate the
error to the module init function and return that.So a later access to any member of cpufreq_driver causes bugs like:
BUG: unable to handle kernel paging request at ffffffffa00270a0
IP: [] cpufreq_cpu_get+0x53/0xe0
PGD 1805067 PUD 1809063 PMD 1c3f90067 PTE 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/net/tun0/statistics/collisions
CPU 0
Modules linked in: ...
Pid: 5677, comm: thunderbird-bin Tainted: G W 2.6.38-rc4-mm1_64+ #1389 To be filled by O.E.M./To Be Filled By O.E.M.
RIP: 0010:[] [] cpufreq_cpu_get+0x53/0xe0
RSP: 0018:ffff8801aec37d98 EFLAGS: 00010086
RAX: 0000000000000202 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffffffffa00270a0 RSI: 0000000000001000 RDI: ffffffff8199ece8
...
Call Trace:
[] cpufreq_quick_get+0x10/0x30
[] show_cpuinfo+0x2ab/0x300
[] seq_read+0xf2/0x3f0
[] ? __strncpy_from_user+0x33/0x60
[] proc_reg_read+0x6d/0xa0
[] vfs_read+0xc3/0x180
[] sys_read+0x4c/0x90
[] system_call_fastpath+0x16/0x1b
...It's all cause by weird fail path handling in cpufreq_register_driver.
To fix that, shuffle the code to do proper handling with gotos.Signed-off-by: Jiri Slaby
Signed-off-by: Dave Jones
26 Jan, 2011
1 commit
-
With cmwq, there's no reason for cpufreq drivers to use separate
workqueues. Remove the dedicated workqueues from cpufreq_conservative
and cpufreq_ondemand and use system_wq instead. The work items are
already sync canceled on stop, so it's already guaranteed that no work
is running on module exit.Signed-off-by: Tejun Heo
Acked-by: Dave Jones
Cc: cpufreq@vger.kernel.org
21 Jan, 2011
1 commit
-
The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel. A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.Reviewed-by: Ingo Molnar
Acked-by: David Woodhouse
Signed-off-by: David Rientjes
Cc: Greg KH
Cc: "David S. Miller"
Cc: Jens Axboe
Cc: Arnd Bergmann
Cc: Robin Holt
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
04 Jan, 2011
1 commit
-
Add these new power trace events:
power:cpu_idle
power:cpu_frequency
power:machine_suspendThe old C-state/idle accounting events:
power:power_start
power:power_endHave now a replacement (but we are still keeping the old
tracepoints for compatibility):power:cpu_idle
and
power:power_frequencyis replaced with:
power:cpu_frequencypower:machine_suspend is newly introduced.
Jean Pihet has a patch integrated into the generic layer
(kernel/power/suspend.c) which will make use of it.the type= field got removed from both, it was never
used and the type is differed by the event type itself.perf timechart userspace tool gets adjusted in a separate patch.
Signed-off-by: Thomas Renninger
Signed-off-by: Ingo Molnar
Acked-by: Arjan van de Ven
Acked-by: Jean Pihet
Cc: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra
Cc: Linus Torvalds
Cc: rjw@sisk.pl
LKML-Reference:
Signed-off-by: Ingo Molnar
LKML-Reference:
22 Oct, 2010
2 commits
-
Adds a new global tunable, sampling_down_factor. Set to 1 it makes no
changes from existing behavior, but set to greater than 1 (e.g. 100)
it acts as a multiplier for the scheduling interval for reevaluating
load when the CPU is at its top speed due to high load. This improves
performance by reducing the overhead of load evaluation and helping
the CPU stay at its top speed when truly busy, rather than shifting
back and forth in speed. This tunable has no effect on behavior at
lower speeds/lower CPU loads.This patch is against 2.6.36-rc6.
This patch should help solve kernel bug 19672 "ondemand is slow".
Signed-off-by: David Niemi
Acked-by: Venkatesh Pallipadi
CC: Daniel Hollocher
CC:
CC:
Signed-off-by: Dave Jones -
Indent the body of for_each_cpu.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)//
@r disable braces4@
position p1,p2;
statement S1,S2;
@@(
if (...) { ... }
|
if (...) S1@p1 S2@p2
)@script:python@
p1 << r.p1;
p2 << r.p2;
@@if (p1[0].column == p2[0].column):
cocci.print_main("branch",p1)
cocci.print_secs("after",p2)
//Signed-off-by: Julia Lawall
Signed-off-by: Dave Jones
04 Aug, 2010
7 commits
-
This patch fixes up a brace warning found by the checkpatch.pl tool
Signed-off-by: Neal Buckendahl
Signed-off-by: Dave Jones -
and fix the broken case if a core's frequency depends on others.
trace_power_frequency was only implemented in a rather ungeneric way
in acpi-cpufreq driver's target() function only.
-> Move the call to trace_power_frequency to
cpufreq.c:cpufreq_notify_transition() where CPUFREQ_POSTCHANGE
notifier is triggered.
This will support power frequency tracing by all cpufreq driverstrace_power_frequency did not trace frequency changes correctly when
the userspace governor was used or when CPU cores' frequency depend
on each other.
-> Moving this into the CPUFREQ_POSTCHANGE notifier and pass the cpu
which gets switched automatically fixes this.Robert Schoene provided some important fixes on top of my initial
quick shot version which are integrated in this patch:
- Forgot some changes in power_end trace (TP_printk/variable names)
- Variable dummy in power_end must now be cpu_id
- Use static 64 bit variable instead of unsigned int for cpu_idSigned-off-by: Thomas Renninger
CC: davej@redhat.com
CC: arjan@infradead.org
CC: linux-kernel@vger.kernel.org
CC: robert.schoene@tu-dresden.de
Tested-by: robert.schoene@tu-dresden.de
Signed-off-by: Dave Jones -
For UP systems this is not required, and results in a more consistent
sample interval.[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Jocelyn Falempe
Signed-off-by: Mike Chan
Signed-off-by: Andrew Morton
Signed-off-by: Dave Jones -
lock_policy_rwsem_* and unlock_policy_rwsem_* functions are scheduled
to be unexported when 2.6.33. Now there are no other callers of them
out of cpufreq.c, unexport them and make them static.Signed-off-by: WANG Cong
Cc: Venkatesh Pallipadi
Signed-off-by: Dave Jones -
Make simpler to read and call.
*** v3 - Always call when powersave_bias is enabled.
Acked-by: Venkatesh Pallipadi
Signed-off-by: Mike Chan
Signed-off-by: Dave Jones -
We didn't free policy->related_cpus in error path err_unlock_policy.
This is catched by following kmemleak report:unreferenced object 0xffff88022a0b96d0 (size 512):
comm "modprobe", pid 886, jiffies 4294689177 (age 780.694s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] create_object+0x186/0x281
[] kmemleak_alloc+0x60/0xa7
[] kmem_cache_alloc_node_notrace+0x120/0x142
[] alloc_cpumask_var_node+0x2c/0xd7
[] alloc_cpumask_var+0x11/0x13
[] zalloc_cpumask_var+0xf/0x11
[] cpufreq_add_dev+0x11f/0x547
[] sysdev_driver_register+0xc2/0x11d
[] cpufreq_register_driver+0xcb/0x1b8
[] 0xffffffffa032e040
[] do_one_initcall+0x5e/0x15c
[] sys_init_module+0xa6/0x1e6
[] system_call_fastpath+0x16/0x1b
[] 0xffffffffffffffffSigned-off-by: Xiaotian Feng
Cc: Thomas Renninger
Cc: Prarit Bhargava
Signed-off-by: Dave Jones -
395913d0b1db37092ea3d9d69b832183b1dd84c5 ("[CPUFREQ] remove rwsem lock
from CPUFREQ_GOV_STOP call (second call site)") is not needed, because
there is no rwsem lock in cpufreq_ondemand and cpufreq_conservative
anymore. Lock should not be released until the work done.Addresses https://bugzilla.kernel.org/show_bug.cgi?id=1594
Signed-off-by: Andrej Gelenberg
Cc: Mathieu Desnoyers
Cc: Venkatesh Pallipadi
Signed-off-by: Andrew Morton
Acked-by: Mathieu Desnoyers
Signed-off-by: Dave Jones
18 May, 2010
1 commit
-
* 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86, hypervisor: add missing
Modify the VMware balloon driver for the new x86_hyper API
x86, hypervisor: Export the x86_hyper* symbols
x86: Clean up the hypervisor layer
x86, HyperV: fix up the license to mshyperv.c
x86: Detect running on a Microsoft HyperV system
x86, cpu: Make APERF/MPERF a normal table-driven flag
x86, k8: Fix build error when K8_NB is disabled
x86, cacheinfo: Disable index in all four subcaches
x86, cacheinfo: Make L3 cache info per node
x86, cacheinfo: Reorganize AMD L3 cache structure
x86, cacheinfo: Turn off L3 cache index disable feature in virtualized environments
x86, cacheinfo: Unify AMD L3 cache index disable checking
cpufreq: Unify sysfs attribute definition macros
powernow-k8: Fix frequency reporting
x86, cpufreq: Add APERF/MPERF support for AMD processors
x86: Unify APERF/MPERF support
powernow-k8: Add core performance boost support
x86, cpu: Add AMD core boosting feature flag to /proc/cpuinfoFix up trivial conflicts in arch/x86/kernel/cpu/intel_cacheinfo.c and
drivers/cpufreq/cpufreq_ondemand.c
10 May, 2010
2 commits
-
Pavel Machek pointed out that not all CPUs have an efficient
idle at high frequency. Specifically, older Intel and various
AMD cpus would get a higher powerusage when copying files from
USB.Mike Chan pointed out that the same is true for various ARM
chips as well.Thomas Renninger suggested to make this a sysfs tunable with a
reasonable default.This patch adds a sysfs tunable for the new behavior, and uses
a very simple function to determine a reasonable default,
depending on the CPU vendor/type.Signed-off-by: Arjan van de Ven
Acked-by: Rik van Riel
Acked-by: Pavel Machek
Acked-by: Peter Zijlstra
Cc: davej@redhat.com
LKML-Reference:
[ minor tidyup ]
Signed-off-by: Ingo Molnar -
The ondemand cpufreq governor uses CPU busy time (e.g. not-idle
time) as a measure for scaling the CPU frequency up or down.
If the CPU is busy, the CPU frequency scales up, if it's idle,
the CPU frequency scales down. Effectively, it uses the CPU busy
time as proxy variable for the more nebulous "how critical is
performance right now" question.This algorithm falls flat on its face in the light of workloads
where you're alternatingly disk and CPU bound, such as the ever
popular "git grep", but also things like startup of programs and
maildir using email clients... much to the chagarin of Andrew
Morton.This patch changes the ondemand algorithm to count iowait time
as busy, not idle, time. As shown in the breakdown cases above,
iowait is performance critical often, and by counting iowait,
the proxy variable becomes a more accurate representation of the
"how critical is performance" question.The problem and fix are both verified with the "perf timechar"
tool.Signed-off-by: Arjan van de Ven
Signed-off-by: Andrew Morton
Signed-off-by: Dave Jones
Reviewed-by: Rik van Riel
Acked-by: Peter Zijlstra
LKML-Reference:
Signed-off-by: Ingo Molnar
09 May, 2010
1 commit
25 Apr, 2010
1 commit
-
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
[CPUFREQ] use max load in conservative governor
[CPUFREQ] fix a lockdep warning
10 Apr, 2010
1 commit
-
Multiple modules used to define those which are with identical
functionality and were needlessly replicated among the different cpufreq
drivers. Push them into the header and remove duplication.Signed-off-by: Borislav Petkov
LKML-Reference:
Reviewed-by: Thomas Renninger
Signed-off-by: H. Peter Anvin
01 Apr, 2010
2 commits
-
Instead of using the load of the last CPU in a package, use the
maximum load of all CPUs in a package.Reported-by: Jean-Christian Goussard
Signed-off-by: Dominik Brodowski
Signed-off-by: Dave Jones -
There is no need to do sysfs_remove_link() or kobject_put() etc.
when policy_rwsem_write is held, move them after releasing the lock.This fixes the lockdep warning:
halt/4071 is trying to acquire lock:
(s_active){++++.+}, at: [] .sysfs_addrm_finish+0x58/0xc0but task is already holding lock:
(&per_cpu(cpu_policy_rwsem, cpu)){+.+.+.}, at: [] .lock_policy_rwsem_write+0x84/0xf4Reported-by: Benjamin Herrenschmidt
Signed-off-by: WANG Cong
Cc: Johannes Berg
Cc: Venkatesh Pallipadi
Signed-off-by: Dave Jones
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
08 Mar, 2010
1 commit
-
Constify struct sysfs_ops.
This is part of the ops structure constification
effort started by Arjan van de Ven et al.Benefits of this constification:
* prevents modification of data that is shared
(referenced) by many other structure instances
at runtime* detects/prevents accidental (but not intentional)
modification attempts on archs that enforce
read-only kernel data at runtime* potentially better optimized code as the compiler
can assume that the const data cannot be changed* the compiler/linker move const data into .rodata
and therefore exclude them from false sharingSigned-off-by: Emese Revfy
Acked-by: David Teigland
Acked-by: Matt Domsch
Acked-by: Maciej Sosnowski
Acked-by: Hans J. Koch
Acked-by: Pekka Enberg
Acked-by: Jens Axboe
Acked-by: Stephen Hemminger
Signed-off-by: Greg Kroah-Hartman
13 Jan, 2010
1 commit
-
Dominik said:
target_freq cannot be below policy->min or above policy->max.
If it were, the whole cpufreq subsystem is broken.But (answer):
I think the "ondemand" governor can ask for a target frequency that is
below policy->min.
...
A patch such as below may be needed to sanitize the target frequency
requested by "ondemand". The "conservative" governor already has this check:Signed-off-by: Thomas Renninger
Signed-off-by: Dave Jones# diff -bur x/drivers/cpufreq/cpufreq_ondemand.c.orig y/drivers/cpufreq/cpufreq_ondemand.c
15 Dec, 2009
1 commit
-
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu: (34 commits)
m68k: rename global variable vmalloc_end to m68k_vmalloc_end
percpu: add missing per_cpu_ptr_to_phys() definition for UP
percpu: Fix kdump failure if booted with percpu_alloc=page
percpu: make misc percpu symbols unique
percpu: make percpu symbols in ia64 unique
percpu: make percpu symbols in powerpc unique
percpu: make percpu symbols in x86 unique
percpu: make percpu symbols in xen unique
percpu: make percpu symbols in cpufreq unique
percpu: make percpu symbols in oprofile unique
percpu: make percpu symbols in tracer unique
percpu: make percpu symbols under kernel/ and mm/ unique
percpu: remove some sparse warnings
percpu: make alloc_percpu() handle array types
vmalloc: fix use of non-existent percpu variable in put_cpu_var()
this_cpu: Use this_cpu_xx in trace_functions_graph.c
this_cpu: Use this_cpu_xx for ftrace
this_cpu: Use this_cpu_xx in nmi handling
this_cpu: Use this_cpu operations in RCU
this_cpu: Use this_cpu ops for VM statistics
...Fix up trivial (famous last words) global per-cpu naming conflicts in
arch/x86/kvm/svm.c
mm/slab.c
25 Nov, 2009
3 commits
-
This interface is mainly intended (and implemented) for ACPI _PPC BIOS
frequency limitations, but other cpufreq drivers can also use it for
similar use-cases.Why is this needed:
Currently it's not obvious why cpufreq got limited.
People see cpufreq/scaling_max_freq reduced, but this could have
happened by:
- any userspace prog writing to scaling_max_freq
- thermal limitations
- hardware (_PPC in ACPI case) limitiationsTherefore export bios_limit (in kHz) to:
- Point the user that it's the BIOS (broken or intended) which limits
frequency
- Export it as a sysfs interface for userspace progs.
While this was a rarely used feature on laptops, there will appear
more and more server implemenations providing "Green IT" features like
allowing the service processor to limit the frequency. People want
to know about HW/BIOS frequency limitations.All ACPI P-state driven cpufreq drivers are covered with this patch:
- powernow-k8
- powernow-k7
- acpi-cpufreqTested with a patched DSDT which limits the first two cores (_PPC returns 1)
via _PPC, exposed by bios_limit:
# echo 2200000 >cpu2/cpufreq/scaling_max_freq
# cat cpu*/cpufreq/scaling_max_freq
2600000
2600000
2200000
2200000
# #scaling_max_freq shows general user/thermal/BIOS limitations# cat cpu*/cpufreq/bios_limit
2600000
2600000
2800000
2800000
# #bios_limit only shows the HW/BIOS limitationCC: Pallipadi Venkatesh
CC: Len Brown
CC: davej@codemonkey.org.uk
CC: linux@dominikbrodowski.netSigned-off-by: Thomas Renninger
Signed-off-by: Dave Jones -
No need to export these symbols; make them static.
cpufreq_add_dev_policy
cpufreq_add_dev_symlink
cpufreq_add_dev_interfaceSigned-off-by: Alex Chiang
Signed-off-by: Dave Jones -
Same adustments that have been added to the ondemand recently.
Signed-off-by: Thomas Renninger
Signed-off-by: Dave Jones
18 Nov, 2009
3 commits
-
Dave,
Attached is an update of my patch against the cpufreq fixes branch.
Before applying the patch I compiled and booted the tree to see if the panic
was still there -- to my surprise it was not. This is because of the conversion
of cpufreq_cpu_governor to a char[].While the panic is kaput, the problem of stale data continues and my patch is
still valid. It is possible to end up with the wrong governor after hotplug
events because CPUFREQ_DEFAULT_GOVERNOR is statically linked to a default,
while the cpu siblings may have had a different governor assigned by a user.ie) the patch is still needed in order to keep the governors assigned
properly when hotplugging devicesSigned-off-by: Prarit Bhargava
Signed-off-by: Dave Jones -
ondemand and conservative governors are messing up time units in the
code path where NO_HZ is not enabled and ignore_nice is set. The walltime
idletime stored is in jiffies and nice time calculation is happening in
microseconds.The problem was reported and diagnosed by Alexander here.
http://marc.info/?l=linux-kernel&m=125752550404513&w=2The patch below fixes this thinko.
Reported-by: Alexander Miller
Tested-by: Alexander Miller
Signed-off-by: Venkatesh Pallipadi
Signed-off-by: Dave Jones -
Currently on governer backup/restore path we storing governor's pointer.
This is wrong because one may unload governor's module after cpu goes
offline. As result use-after-free will take place on restored cpu.
It is not easy to exploit this bug, but still we have to close this
issue ASAP. Issue was introduced by following commit
084f34939424161669467c19280dbcf637730314##TESTCASE##
#!/bin/sh -x
modprobe acpi_cpufreq
# Any non default governor, in may case it is "ondemand"
modprobe cpufreq_ondemand
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
rmmod acpi_cpufreq
rmmod cpufreq_ondemand
modprobe acpi_cpufreq # << use-after-free here.Signed-off-by: Dmitry Monakhov
Signed-off-by: Dave Jones
