linux-stable.git/drivers/cpufreq, branch linux-2.6.38.y

Fix memory leak in cpufreq_stat

2011-06-03T01:33:34+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

CPU hotplug, re-create sysfs directory and symlinks

2011-06-03T01:33:33+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

[CPUFREQ] fix BUG on cpufreq policy init failure

2011-03-01T23:49:44+00:00

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

kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT

2011-01-21T01:02:05+00:00

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

perf: Clean up power events by introducing new, more generic ones

2011-01-04T07:16:54+00:00

Add these new power trace events:

 power:cpu_idle
 power:cpu_frequency
 power:machine_suspend

The old C-state/idle accounting events:
  power:power_start
  power:power_end

Have now a replacement (but we are still keeping the old
tracepoints for compatibility):

  power:cpu_idle

and
  power:power_frequency

is replaced with:
  power:cpu_frequency

power: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: <1294073445-14812-3-git-send-email-trenn@suse.de>
Signed-off-by: Ingo Molnar 
LKML-Reference: <1290072314-31155-2-git-send-email-trenn@suse.de>

[CPUFREQ] add sampling_down_factor tunable to improve ondemand performance

2010-10-22T15:44:47+00:00

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

[CPUFREQ] drivers/cpufreq: Adjust confusing if indentation

2010-10-22T15:44:47+00:00

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

[CPUFREQ] fix brace coding style issue.

2010-08-03T17:47:05+00:00

This patch fixes up a brace warning found by the checkpatch.pl tool

Signed-off-by: Neal Buckendahl 
Signed-off-by: Dave Jones

[CPUFREQ] x86 cpufreq: Make trace_power_frequency cpufreq driver independent

2010-08-03T17:47:05+00:00

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 drivers

trace_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_id

Signed-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

[CPUFREQ] ondemand: don't synchronize sample rate unless multiple cpus present

2010-08-03T17:47:04+00:00

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