kernel/linux.git/drivers/cpufreq, branch linux-2.6.35.y

CPUFREQ: Remove cpufreq_stats sysfs entries on module unload.

2011-08-01T20:54:56+00:00

commit 13f067537f34456443f61c950cd6dc37d1d5f3ee upstream. cpufreq_stats leaves behind its sysfs entries, which causes a panic when something stumbled across them. (Discovered by unloading cpufreq_stats while powertop was loaded). Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

Fix memory leak in cpufreq_stat

2011-08-01T20:54:50+00:00

commit 98586ed8b8878e10691203687e89a42fa3355300 upstream. When a CPU is taken offline in an SMP system, cpufreq_remove_dev() nulls out the per-cpu policy before cpufreq_stats_free_table() can make use of it. cpufreq_stats_free_table() then skips the call to sysfs_remove_group(), leaving about 100 bytes of sysfs-related memory unclaimed each time a CPU-removal occurs. Break up cpu_stats_free_table into sysfs and table portions, and call the sysfs portion early. Signed-off-by: Steven Finney Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

CPU hotplug, re-create sysfs directory and symlinks

2011-08-01T20:54:49+00:00

commit 27ecddc2a9f99ce4ac9a59a0acd77f7100b6d034 upstream. When we discover CPUs that are affected by each other's frequency/voltage transitions, the first CPU gets a sysfs directory created, and rest of the siblings get symlinks. Currently, when we hotplug off only the first CPU, all of the symlinks and the sysfs directory gets removed. Even though rest of the siblings are still online and functional, they are orphaned, and no longer governed by cpufreq. This patch, given the above scenario, creates a sysfs directory for the first sibling and symlinks for the rest of the siblings. Please note the recursive call, it was rather too ugly to roll it out. And the removal of redundant NULL setting (it is already taken care of near the top of the function). Signed-off-by: Jacob Shin Acked-by: Mark Langsdorf Reviewed-by: Thomas Renninger Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

[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