.TH CPUPOWER\-SET "1" "22/02/2011" "" "cpupower Manual" .SH NAME cpupower\-set \- Set processor power related kernel or hardware configurations .SH SYNOPSIS .ft B .B cpupower set [ \-b VAL ] .SH DESCRIPTION \fBcpupower set \fP sets kernel configurations or directly accesses hardware registers affecting processor power saving policies. Some options are platform wide, some affect single cores. By default values are applied on all cores. How to modify single core configurations is described in the cpupower(1) manpage in the \-\-cpu option section. Whether an option affects the whole system or can be applied to individual cores is described in the Options sections. Use \fBcpupower info \fP to read out current settings and whether they are supported on the system at all. .SH Options .PP \-\-perf-bias, \-b .RS 4 Sets a register on supported Intel processore which allows software to convey its policy for the relative importance of performance versus energy savings to the processor. The range of valid numbers is 0-15, where 0 is maximum performance and 15 is maximum energy efficiency. The processor uses this information in model-specific ways when it must select trade-offs between performance and energy efficiency. This policy hint does not supersede Processor Performance states (P-states) or CPU Idle power states (C-states), but allows software to have influence where it would otherwise be unable to express a preference. For example, this setting may tell the hardware how aggressively or conservatively to control frequency in the "turbo range" above the explicitly OS-controlled P-state frequency range. It may also tell the hardware how aggressively it should enter the OS requested C-states. This option can be applied to individual cores only via the \-\-cpu option, cpupower(1). Setting the performance bias value on one CPU can modify the setting on related CPUs as well (for example all CPUs on one socket), because of hardware restrictions. Use \fBcpupower -c all info -b\fP to verify. This options needs the msr kernel driver (CONFIG_X86_MSR) loaded. .RE .SH "SEE ALSO" cpupower-info(1), cpupower-monitor(1), powertop(1) .PP .SH AUTHORS .nf \-\-perf\-bias parts written by Len Brown Thomas Renninger ds-private-remove&id=966d2b04e070bc040319aaebfec09e0144dc3341'>diff
diff options
context:
space:
mode:
authorDouglas Miller <dougmill@linux.vnet.ibm.com>2017-01-28 06:42:20 -0600
committerTejun Heo <tj@kernel.org>2017-01-28 07:49:42 -0500
commit966d2b04e070bc040319aaebfec09e0144dc3341 (patch)
tree4b96156e3d1dd4dfd6039b7c219c9dc4616da52d /kernel/locking/lockdep_proc.c
parent1b1bc42c1692e9b62756323c675a44cb1a1f9dbd (diff)
percpu-refcount: fix reference leak during percpu-atomic transition
percpu_ref_tryget() and percpu_ref_tryget_live() should return "true" IFF they acquire a reference. But the return value from atomic_long_inc_not_zero() is a long and may have high bits set, e.g. PERCPU_COUNT_BIAS, and the return value of the tryget routines is bool so the reference may actually be acquired but the routines return "false" which results in a reference leak since the caller assumes it does not need to do a corresponding percpu_ref_put(). This was seen when performing CPU hotplug during I/O, as hangs in blk_mq_freeze_queue_wait where percpu_ref_kill (blk_mq_freeze_queue_start) raced with percpu_ref_tryget (blk_mq_timeout_work). Sample stack trace: __switch_to+0x2c0/0x450 __schedule+0x2f8/0x970 schedule+0x48/0xc0 blk_mq_freeze_queue_wait+0x94/0x120 blk_mq_queue_reinit_work+0xb8/0x180 blk_mq_queue_reinit_prepare+0x84/0xa0 cpuhp_invoke_callback+0x17c/0x600 cpuhp_up_callbacks+0x58/0x150 _cpu_up+0xf0/0x1c0 do_cpu_up+0x120/0x150 cpu_subsys_online+0x64/0xe0 device_online+0xb4/0x120 online_store+0xb4/0xc0 dev_attr_store+0x68/0xa0 sysfs_kf_write+0x80/0xb0 kernfs_fop_write+0x17c/0x250 __vfs_write+0x6c/0x1e0 vfs_write+0xd0/0x270 SyS_write+0x6c/0x110 system_call+0x38/0xe0 Examination of the queue showed a single reference (no PERCPU_COUNT_BIAS, and __PERCPU_REF_DEAD, __PERCPU_REF_ATOMIC set) and no requests. However, conditions at the time of the race are count of PERCPU_COUNT_BIAS + 0 and __PERCPU_REF_DEAD and __PERCPU_REF_ATOMIC set. The fix is to make the tryget routines use an actual boolean internally instead of the atomic long result truncated to a int. Fixes: e625305b3907 percpu-refcount: make percpu_ref based on longs instead of ints Link: https://bugzilla.kernel.org/show_bug.cgi?id=190751 Signed-off-by: Douglas Miller <dougmill@linux.vnet.ibm.com> Reviewed-by: Jens Axboe <axboe@fb.com> Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: e625305b3907 ("percpu-refcount: make percpu_ref based on longs instead of ints") Cc: stable@vger.kernel.org # v3.18+
Diffstat (limited to 'kernel/locking/lockdep_proc.c')