lwn.git/drivers/cpufreq, branch v2.6.35

[CPUFREQ] fix memory leak in cpufreq_add_dev

2010-07-26T19:25:33+00:00

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 [] 0xffffffffffffffff Signed-off-by: Xiaotian Feng Cc: Thomas Renninger Cc: Prarit Bhargava Signed-off-by: Dave Jones

[CPUFREQ] revert "[CPUFREQ] remove rwsem lock from CPUFREQ_GOV_STOP call (second call site)"

2010-07-26T19:25:33+00:00

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

Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2010-05-18T15:49:13+00:00

* '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/cpuinfo Fix up trivial conflicts in arch/x86/kernel/cpu/intel_cacheinfo.c and drivers/cpufreq/cpufreq_ondemand.c

ondemand: Make the iowait-is-busy time a sysfs tunable

2010-05-09T17:35:27+00:00

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: <20100509082651.46914d04@infradead.org> [ minor tidyup ] Signed-off-by: Ingo Molnar

ondemand: Solve a big performance issue by counting IOWAIT time as busy

2010-05-09T17:35:27+00:00

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: <20100509082606.3d9f00d0@infradead.org> Signed-off-by: Ingo Molnar

Merge commit 'v2.6.34-rc6' into x86/cpu

2010-05-08T21:59:58+00:00

Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq

2010-04-24T18:35:21+00:00

* '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

cpufreq: Unify sysfs attribute definition macros

2010-04-09T21:07:56+00:00

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: <1270065406-1814-7-git-send-email-bp@amd64.org> Reviewed-by: Thomas Renninger Signed-off-by: H. Peter Anvin

[CPUFREQ] use max load in conservative governor

2010-03-31T16:00:22+00:00

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

[CPUFREQ] fix a lockdep warning

2010-03-31T16:00:21+00:00

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/0xc0 but task is already holding lock: (&per_cpu(cpu_policy_rwsem, cpu)){+.+.+.}, at: [] .lock_policy_rwsem_write+0x84/0xf4 Reported-by: Benjamin Herrenschmidt Signed-off-by: WANG Cong Cc: Johannes Berg Cc: Venkatesh Pallipadi Signed-off-by: Dave Jones