23 Feb, 2017
1 commit
-
Interactive governor has lived in Android sources for a very long time
and this commit is based on the code present in following branch:https://android.googlesource.com/kernel/common android-4.4
The Interactive governor is designed for latency-sensitive workloads,
such as interactive user interfaces like the mobile phones and tablets.
The interactive governor aims to be significantly more responsive to
ramp CPU quickly up when CPU-intensive activity begins.Existing governors sample CPU load at a particular rate, typically every
X ms and then update the frequency from a work-handler. This can lead
to under-powering UI threads for the period of time during which the
user begins interacting with a previously-idle system until the next
sample period happens.The 'interactive' governor uses a different approach.
A real-time thread is used for scaling up, giving the remaining tasks
the CPU performance benefit, unlike existing governors which are more
likely to schedule ramp-up work to occur after your performance starved
tasks have completed.The Android version of interactive governor also checks whether to scale
the CPU frequency up soon after coming out of idle. When the CPU comes
out of idle, the governor check if the CPU sampling is overdue or not.
If yes, it immediately starts the sampling. Otherwise, the utilization
hooks from the scheduler handle the sampling later. If the CPU is very
busy from exiting idle to when the evaluation happens, then it assumes
that the CPU is under-powered and ramps it to MAX speed.If the CPU was not sufficiently busy to immediately ramp to MAX speed,
then the governor evaluates the CPU load since the last speed
adjustment, choosing the highest value between that longer-term load or
the short-term load since idle exit to determine the CPU speed to ramp
to.Idle notifiers will be be handled later and are not included for now.
The core of this code is written and maintained (in Android
repositories) by Mike Chan and Todd Poyner over a long period of time.Vireshk has made changes to to the governor to align it with the current
practices followed with mainline governors, like using utilization hooks
from the scheduler and handling kobject (for governor's sysfs directory)
in a race free manner. And of course this included general cleanup of
the governor as well.Signed-off-by: Mike Chan
Signed-off-by: Todd Poynor
Signed-off-by: Viresh Kumar---
V1->V2:
- Changes to fix compilation issues with updated mainline
- Timer APIs got updated
- s/mod_timer_pinned/mod_timer
- s/init_timer/init_timer_pinned
- Updated prototypes of cpufreq_frequency_table_target() and
update_util_handler()
09 Sep, 2016
1 commit
-
The cpufreq-stats code can no longer be built as a module, so it now
appears with square brackets in menuconfig.Signed-off-by: Jean Delvare
Fixes: 1aefc75b2449 (cpufreq: stats: Make the stats code non-modular)
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
23 Jul, 2016
1 commit
-
This reverts commit 790d849bf811a8ab5d4cd2cce0f6fda92f6aebf2.
Using a v4.7-rc7 kernel on a HP ProLiant triggered following messages
pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governorThe last line was shown for each CPU in the system.
Testing v4.5 (where commit 790d849b was integrated) triggered
similar messages. Same behaviour on a 2nd HP Proliant system.So commit 790d849bf (cpufreq: pcc-cpufreq: update default value of
cpuinfo_transition_latency) causes the system to use performance
governor which, I guess, was not the intention of the patch.Enabling debug output in pcc-cpufreq provides following verbose output:
pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
pcc_get_offset: for CPU 0: pcc_cpu_data input_offset: 0x44, pcc_cpu_data output_offset: 0x48
init: policy->max is 2800000, policy->min is 1200000
get: get_freq for CPU 0
get: SUCCESS: (virtual) output_offset for cpu 0 is 0xffffc9000d7c0048, contains a value of: 0xff06. Speed is: 168000 MHz
cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor
target: CPU 0 should go to target freq: 2800000 (virtual) input_offset is 0xffffc9000d7c0044
target: was SUCCESSFUL for cpu 0I am asking to revert 790d849bf to re-enable usage of ondemand
governor with pcc-cpufreq.Fixes: 790d849bf (cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency)
CC: # 4.5+
Signed-off-by: Andreas Herrmann
Signed-off-by: Rafael J. Wysocki
09 Jun, 2016
2 commits
-
This routine can't fail unless the frequency table is invalid and
doesn't contain any valid entries.Make it return the index and WARN() in case it is used for an invalid
table.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
The policy already has this pointer set, use it instead.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
03 Jun, 2016
1 commit
-
All cpufreq drivers with a freq-table are migrated to use
cpufreq_table_validate_and_show() long back and the routine
cpufreq_frequency_table_cpuinfo() isn't used outside of cpufreq core
now.Unexport it and update Documentation as well.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
19 Feb, 2016
1 commit
-
This just swaps a colon for a quote in the intel_pstate documentation.
Signed-off-by: Felipe Franciosi
Signed-off-by: Rafael J. Wysocki
05 Jan, 2016
1 commit
-
This is an attempt to make documentation more user friendly.
Signed-off-by: Srinivas Pandruvada
Reviewed-by: Doug Smythies
Reviewed-by: Chen, Yu C
Signed-off-by: Rafael J. Wysocki
10 Dec, 2015
1 commit
-
The cpufreq documentation specifies
policy->cpuinfo.transition_latency the time it takes on this CPU to
switch between two frequencies in
nanoseconds (if appropriate, else
specify CPUFREQ_ETERNAL)currently pcc-cpufreq does not expose the value and sets it to zero. I
changed the pcc-cpufreq driver and it's documentation to conform to the
default value specified in Documentation/cpu-freq/cpu-drivers.txtSigned-off-by: Jacob Tanenbaum
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
01 Sep, 2015
1 commit
-
What's being done from CPUFREQ_INCOMPATIBLE, can also be done with
CPUFREQ_ADJUST. There is nothing special with CPUFREQ_INCOMPATIBLE
notifier.Kill CPUFREQ_INCOMPATIBLE and fix its usage sites.
This also updates the numbering of notifier events to remove holes.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
25 Jun, 2015
1 commit
-
Pull documentation updates from Jonathan Corbet:
"The main thing here is Ingo's big subdirectory documenting feature
support for each architecture. Beyond that, it's the usual pile of
fixes, tweaks, and small additions"* tag 'docs-for-linus' of git://git.lwn.net/linux-2.6: (79 commits)
doc:md: fix typo in md.txt.
Documentation/mic/mpssd: don't build x86 userspace when cross compiling
Documentation/prctl: don't build tsc tests when cross compiling
Documentation/vDSO: don't build tests when cross compiling
Doc:ABI/testing: Fix typo in sysfs-bus-fcoe
Doc: Docbook: Change wikipedia's URL from http to https in scsi.tmpl
Doc: Change wikipedia's URL from http to https
Documentation/kernel-parameters: add missing pciserial to the earlyprintk
Doc:pps: Fix typo in pps.txt
kbuild : Fix documentation of INSTALL_HDR_PATH
Documentation: filesystems: updated struct file_operations documentation in vfs.txt
kbuild: edit explanation of clean-files variable
Doc: ja_JP: Fix typo in HOWTO
Move freefall program from Documentation/ to tools/
Documentation: ARM: EXYNOS: Describe boot loaders interface
Doc:nfc: Fix typo in nfc-hci.txt
vfs: Minor documentation fix
Doc: networking: txtimestamp: fix printf format warning
Documentation, intel_pstate: Improve legacy mode internal governors description
Documentation: extend use case for EXPORT_SYMBOL_GPL()
...
05 Jun, 2015
1 commit
-
The current documentation is incomplete wrt the intel_pstate legacy
internal governors. The confusion comes from the general cpufreq
governors which also use the names performance and powersave. This patch
better differentiates between the two sets of governors and gives an
explanation of how the internal P-state governors behave differently from
one another.Also fix two minor typos.
Cc: Prarit Bhargava
Cc: "Rafael J. Wysocki"
Cc: Kristen Carlson Accardi
Cc: Dirk Brandewie
Cc: x86@kernel.org
Acked-by: Viresh Kumar
Signed-off-by: Prarit Bhargava
Signed-off-by: Jonathan Corbet
06 May, 2015
1 commit
-
The file 'Documentation/cpu-freq/user-guide.txt' has duplicate
description of sysfs interface 'scaling_driver'.[first]
scaling_driver : this file shows what cpufreq driver is
used to set the frequency on this CPU[second]
scaling_driver : Hardware driver for cpufreq.Although this does not affect anything, I think we should only have
one. so delete the second one because the first one is described in
more detail.Signed-off-by: Wang Long
Signed-off-by: Rafael J. Wysocki
30 Jan, 2015
2 commits
-
Add a sysfs interface to display the total number of supported
pstates. This value is independent of whether turbo has been
enabled or disabled.Signed-off-by: Kristen Carlson Accardi
Signed-off-by: Rafael J. Wysocki -
This patch adds "turbo_pct" to the intel_pstate sysfs interface.
turbo_pct will display the percentage of the total supported
pstates that are in the turbo range. This value is independent
of whether turbo has been disabled or not.Signed-off-by: Kristen Carlson Accardi
Signed-off-by: Rafael J. Wysocki
12 Nov, 2014
1 commit
-
Add support of Hardware Managed Performance States (HWP) described in Volume 3
section 14.4 of the SDM.With HWP enbaled intel_pstate will no longer be responsible for selecting P
states for the processor. intel_pstate will continue to register to
the cpufreq core as the scaling driver for CPUs implementing
HWP. In HWP mode intel_pstate provides three functions reporting
frequency to the cpufreq core, support for the set_policy() interface
from the core and maintaining the intel_pstate sysfs interface in
/sys/devices/system/cpu/intel_pstate. User preferences expressed via
the set_policy() interface or the sysfs interface are forwared to the
CPU via the HWP MSR interface.Signed-off-by: Dirk Brandewie
Signed-off-by: Rafael J. Wysocki
07 Jul, 2014
1 commit
-
Update documentation to make the interpretation of the values clearer
Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251
Cc: 3.13+ # 3.13+
Signed-off-by: Dirk Brandewie
Signed-off-by: Rafael J. Wysocki
06 Jun, 2014
1 commit
-
Douglas Anderson, recently pointed out an interesting problem due to which
udelay() was expiring earlier than it should.While transitioning between frequencies few platforms may temporarily switch to
a stable frequency, waiting for the main PLL to stabilize.For example: When we transition between very low frequencies on exynos, like
between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz.
No CPUFREQ notification is sent for that. That means there's a period of time
when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz
and 300MHz. And so udelay behaves badly.To get this fixed in a generic way, introduce another set of callbacks
get_intermediate() and target_intermediate(), only for drivers with
target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.get_intermediate() should return a stable intermediate frequency platform wants
to switch to, and target_intermediate() should set CPU to that frequency,
before jumping to the frequency corresponding to 'index'. Core will take care of
sending notifications and driver doesn't have to handle them in
target_intermediate() or target_index().NOTE: ->target_index() should restore to policy->restore_freq in case of
failures as core would send notifications for that.Tested-by: Stephen Warren
Signed-off-by: Viresh Kumar
Reviewed-by: Doug Anderson
Signed-off-by: Rafael J. Wysocki
07 May, 2014
1 commit
-
CPUFreq specific helper functions for OPP (Operating Performance Points)
now use generic OPP functions that allow CPUFreq to be be moved back
into CPUFreq framework. This allows for independent modifications
or future enhancements as needed isolated to just CPUFreq framework
alone.Here, we just move relevant code and documentation to make this part of
CPUFreq infrastructure.Cc: Kevin Hilman
Signed-off-by: Nishanth Menon
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
01 May, 2014
1 commit
-
There has been confusion all the time about which mailing list to follow
for cpufreq activities, linux-pm@vger.kernel.org or cpufreq@vger.kernel.org.Since patches sent to cpufreq@vger.kernel.org don't go to Patchwork
which is a maintenance workflow problem, make linux-pm@vger.kernel.org
the official mailing list for cpufreq stuff and remove all references
of cpufreq@vger.kernel.org from kernel source.Later, we can request that the list be dropped entirely.
Signed-off-by: Viresh Kumar
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki
30 Apr, 2014
1 commit
-
Many cpufreq drivers need to iterate over the cpufreq_frequency_table
for various tasks.This patch introduces two macros which can be used for iteration over
cpufreq_frequency_table keeping a common coding style across drivers:- cpufreq_for_each_entry: iterate over each entry of the table
- cpufreq_for_each_valid_entry: iterate over each entry that contains
a valid frequency.It should have no functional changes.
Signed-off-by: Stratos Karafotis
Acked-by: Lad, Prabhakar
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
20 Mar, 2014
1 commit
-
This callback allows the driver to do clean up before the CPU is
completely down and its state cannot be modified. This is used
by the intel_pstate driver to reduce the requested P state prior to
the core going away. This is required because the requested P state
of the offline core is used to select the package P state. This
effectively sets the floor package P state to the requested P state on
the offline core.Signed-off-by: Dirk Brandewie
[rjw: Minor modifications]
Signed-off-by: Rafael J. Wysocki
19 Mar, 2014
1 commit
-
Two cpufreq notifiers CPUFREQ_RESUMECHANGE and CPUFREQ_SUSPENDCHANGE have
not been used for some time, so remove them to clean up code a bit.Signed-off-by: Viresh Kumar
Reviewed-by: Srivatsa S. Bhat
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki
17 Jan, 2014
1 commit
-
Since the support for software and hardware controlled boosting has
been added, update the corresponding documentation.Signed-off-by: Lukasz Majewski
Signed-off-by: Myungjoo Ham
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
06 Jan, 2014
1 commit
-
The Intel P-state driver is currently undocumented. Add some
documentation based on the cover-letter sent with the original series.Cc: Dirk Brandewie
Acked-by: Randy Dunlap
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Rafael J. Wysocki
26 Oct, 2013
1 commit
-
Currently, the prototype of cpufreq_drivers target routines is:
int target(struct cpufreq_policy *policy, unsigned int target_freq,
unsigned int relation);And most of the drivers call cpufreq_frequency_table_target() to get a valid
index of their frequency table which is closest to the target_freq. And they
don't use target_freq and relation after that.So, it makes sense to just do this work in cpufreq core before calling
cpufreq_frequency_table_target() and simply pass index instead. But this can be
done only with drivers which expose their frequency table with cpufreq core. For
others we need to stick with the old prototype of target() until those drivers
are converted to expose frequency tables.This patch implements the new light weight prototype for target_index() routine.
It looks like this:int target_index(struct cpufreq_policy *policy, unsigned int index);
CPUFreq core will call cpufreq_frequency_table_target() before calling this
routine and pass index to it. Because CPUFreq core now requires to call routines
present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.This also marks target() interface as deprecated. So, that new drivers avoid
using it. And Documentation is updated accordingly.It also converts existing .target() to newly defined light weight
.target_index() routine for many driver.Acked-by: Hans-Christian Egtvedt
Acked-by: Jesper Nilsson
Acked-by: Linus Walleij
Acked-by: Russell King
Acked-by: David S. Miller
Tested-by: Andrew Lunn
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
10 Aug, 2013
1 commit
-
We don't need to set .owner = THIS_MODULE any more in cpufreq drivers
as this field isn't used any more by the cpufreq core.This patch removes it and updates all dependent drivers accordingly.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
04 Jun, 2013
1 commit
-
The "index" field of struct cpufreq_frequency_table was never an
index and isn't used at all by the cpufreq core. It only is useful
for cpufreq drivers for their internal purposes.Many people nowadays blindly set it in ascending order with the
assumption that the core will use it, which is a mistake.Rename it to "driver_data" as that's what its purpose is. All of its
users are updated accordingly.[rjw: Changelog]
Signed-off-by: Viresh Kumar
Acked-by: Simon Horman
Signed-off-by: Rafael J. Wysocki
06 May, 2013
1 commit
-
Pull 'full dynticks' support from Ingo Molnar:
"This tree from Frederic Weisbecker adds a new, (exciting! :-) core
kernel feature to the timer and scheduler subsystems: 'full dynticks',
or CONFIG_NO_HZ_FULL=y.This feature extends the nohz variable-size timer tick feature from
idle to busy CPUs (running at most one task) as well, potentially
reducing the number of timer interrupts significantly.This feature got motivated by real-time folks and the -rt tree, but
the general utility and motivation of full-dynticks runs wider than
that:- HPC workloads get faster: CPUs running a single task should be able
to utilize a maximum amount of CPU power. A periodic timer tick at
HZ=1000 can cause a constant overhead of up to 1.0%. This feature
removes that overhead - and speeds up the system by 0.5%-1.0% on
typical distro configs even on modern systems.- Real-time workload latency reduction: CPUs running critical tasks
should experience as little jitter as possible. The last remaining
source of kernel-related jitter was the periodic timer tick.- A single task executing on a CPU is a pretty common situation,
especially with an increasing number of cores/CPUs, so this feature
helps desktop and mobile workloads as well.The cost of the feature is mainly related to increased timer
reprogramming overhead when a CPU switches its tick period, and thus
slightly longer to-idle and from-idle latency.Configuration-wise a third mode of operation is added to the existing
two NOHZ kconfig modes:- CONFIG_HZ_PERIODIC: [formerly !CONFIG_NO_HZ], now explicitly named
as a config option. This is the traditional Linux periodic tick
design: there's a HZ tick going on all the time, regardless of
whether a CPU is idle or not.- CONFIG_NO_HZ_IDLE: [formerly CONFIG_NO_HZ=y], this turns off the
periodic tick when a CPU enters idle mode.- CONFIG_NO_HZ_FULL: this new mode, in addition to turning off the
tick when a CPU is idle, also slows the tick down to 1 Hz (one
timer interrupt per second) when only a single task is running on a
CPU.The .config behavior is compatible: existing !CONFIG_NO_HZ and
CONFIG_NO_HZ=y settings get translated to the new values, without the
user having to configure anything. CONFIG_NO_HZ_FULL is turned off by
default.This feature is based on a lot of infrastructure work that has been
steadily going upstream in the last 2-3 cycles: related RCU support
and non-periodic cputime support in particular is upstream already.This tree adds the final pieces and activates the feature. The pull
request is marked RFC because:- it's marked 64-bit only at the moment - the 32-bit support patch is
small but did not get ready in time.- it has a number of fresh commits that came in after the merge
window. The overwhelming majority of commits are from before the
merge window, but still some aspects of the tree are fresh and so I
marked it RFC.- it's a pretty wide-reaching feature with lots of effects - and
while the components have been in testing for some time, the full
combination is still not very widely used. That it's default-off
should reduce its regression abilities and obviously there are no
known regressions with CONFIG_NO_HZ_FULL=y enabled either.- the feature is not completely idempotent: there is no 100%
equivalent replacement for a periodic scheduler/timer tick. In
particular there's ongoing work to map out and reduce its effects
on scheduler load-balancing and statistics. This should not impact
correctness though, there are no known regressions related to this
feature at this point.- it's a pretty ambitious feature that with time will likely be
enabled by most Linux distros, and we'd like you to make input on
its design/implementation, if you dislike some aspect we missed.
Without flaming us to crisp! :-)Future plans:
- there's ongoing work to reduce 1Hz to 0Hz, to essentially shut off
the periodic tick altogether when there's a single busy task on a
CPU. We'd first like 1 Hz to be exposed more widely before we go
for the 0 Hz target though.- once we reach 0 Hz we can remove the periodic tick assumption from
nr_running>=2 as well, by essentially interrupting busy tasks only
as frequently as the sched_latency constraints require us to do -
once every 4-40 msecs, depending on nr_running.I am personally leaning towards biting the bullet and doing this in
v3.10, like the -rt tree this effort has been going on for too long -
but the final word is up to you as usual.More technical details can be found in Documentation/timers/NO_HZ.txt"
* 'timers-nohz-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (39 commits)
sched: Keep at least 1 tick per second for active dynticks tasks
rcu: Fix full dynticks' dependency on wide RCU nocb mode
nohz: Protect smp_processor_id() in tick_nohz_task_switch()
nohz_full: Add documentation.
cputime_nsecs: use math64.h for nsec resolution conversion helpers
nohz: Select VIRT_CPU_ACCOUNTING_GEN from full dynticks config
nohz: Reduce overhead under high-freq idling patterns
nohz: Remove full dynticks' superfluous dependency on RCU tree
nohz: Fix unavailable tick_stop tracepoint in dynticks idle
nohz: Add basic tracing
nohz: Select wide RCU nocb for full dynticks
nohz: Disable the tick when irq resume in full dynticks CPU
nohz: Re-evaluate the tick for the new task after a context switch
nohz: Prepare to stop the tick on irq exit
nohz: Implement full dynticks kick
nohz: Re-evaluate the tick from the scheduler IPI
sched: New helper to prevent from stopping the tick in full dynticks
sched: Kick full dynticks CPU that have more than one task enqueued.
perf: New helper to prevent full dynticks CPUs from stopping tick
perf: Kick full dynticks CPU if events rotation is needed
...
10 Apr, 2013
1 commit
-
Future AMD processors, starting with Family 16h, can provide software
with feedback on how the workload may respond to frequency change --
memory-bound workloads will not benefit from higher frequency, where
as compute-bound workloads will. This patch enables this "frequency
sensitivity feedback" to aid the ondemand governor to make better
frequency change decisions by hooking into the powersave bias.Signed-off-by: Jacob Shin
Acked-by: Thomas Renninger
Acked-by: Borislav Petkov
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
03 Apr, 2013
1 commit
-
We are planning to convert the dynticks Kconfig options layout
into a choice menu. The user must be able to easily pick
any of the following implementations: constant periodic tick,
idle dynticks, full dynticks.As this implies a mutual exclusion, the two dynticks implementions
need to converge on the selection of a common Kconfig option in order
to ease the sharing of a common infrastructure.It would thus seem pretty natural to reuse CONFIG_NO_HZ to
that end. It already implements all the idle dynticks code
and the full dynticks depends on all that code for now.
So ideally the choice menu would propose CONFIG_NO_HZ_IDLE and
CONFIG_NO_HZ_EXTENDED then both would select CONFIG_NO_HZ.On the other hand we want to stay backward compatible: if
CONFIG_NO_HZ is set in an older config file, we want to
enable CONFIG_NO_HZ_IDLE by default.But we can't afford both at the same time or we run into
a circular dependency:1) CONFIG_NO_HZ_IDLE and CONFIG_NO_HZ_EXTENDED both select
CONFIG_NO_HZ
2) If CONFIG_NO_HZ is set, we default to CONFIG_NO_HZ_IDLEWe might be able to support that from Kconfig/Kbuild but it
may not be wise to introduce such a confusing behaviour.So to solve this, create a new CONFIG_NO_HZ_COMMON option
which gathers the common code between idle and full dynticks
(that common code for now is simply the idle dynticks code)
and select it from their referring Kconfig.Then we'll later create CONFIG_NO_HZ_IDLE and map CONFIG_NO_HZ
to it for backward compatibility.Signed-off-by: Frederic Weisbecker
Cc: Andrew Morton
Cc: Chris Metcalf
Cc: Christoph Lameter
Cc: Geoff Levand
Cc: Gilad Ben Yossef
Cc: Hakan Akkan
Cc: Ingo Molnar
Cc: Kevin Hilman
Cc: Li Zhong
Cc: Namhyung Kim
Cc: Paul E. McKenney
Cc: Paul Gortmaker
Cc: Peter Zijlstra
Cc: Steven Rostedt
Cc: Thomas Gleixner
02 Apr, 2013
2 commits
-
Some assignments of policy-> min/max/cur/cpuinfo.min_freq/cpuinfo.max_freq
aren't required as part of it is done by cpufreq driver or cpufreq core.Remove them.
At some places we merge multiple lines together too.
Signed-off-by: Viresh Kumar
Acked-by: Sekhar Nori
Signed-off-by: Rafael J. Wysocki -
At few places in documentation cpufreq_frequency_table is written as
cpufreq_freq_table. Fix these.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
01 Apr, 2013
1 commit
-
sampling_down_factor tunable is unused since commit
8e677ce83bf41ba9c74e5b6d9ee60b07d4e5ed93 (4 years ago).This patch restores the original functionality and documents the
tunable.Signed-off-by: Stratos Karafotis
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
02 Feb, 2013
1 commit
-
Documentation related to cpus and related_cpus is confusing and not very clear.
Over that CPUFreq core has seen much changes recently. Lets update documentation
and comments for cpus and related_cpus.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
10 Sep, 2012
1 commit
-
One feature present in powernow-k8 that isn't present in acpi-cpufreq
is support for enabling or disabling AMD's core performance boost
technology. This patch adds support to acpi-cpufreq, but also
includes support for Intel's dynamic acceleration.The original boost disabling sysfs file was per CPU, but acted
globally. Also the naming (cpb) was at least not intuitive.
So lets introduce a single file simply called "boost", which sits
once in /sys/devices/system/cpu/cpufreq.
This should be the only way of using this feature, so add
documentation about the rationale and the usage.A following patch will re-introduce the cpb knob for compatibility
reasons on AMD CPUs.Per-CPU boost switching is possible, but not trivial and is thus
postponed to a later patch series.Signed-off-by: Andre Przywara
Signed-off-by: Rafael J. Wysocki
08 Nov, 2011
1 commit
-
'sampling_rate_max' was removed with commit ef598549 ("[...] Remove
deprecated sysfs file sampling_rate_max"), so its line can be dropped
from governors.txt. And 'show_sampling_rate_min' is a typo: the sysfs
file is called 'sampling_rate_min'.Signed-off-by: Paul Bolle
Signed-off-by: Jiri Kosina
09 Aug, 2011
1 commit
-
Signed-off-by: Paul Bolle
Acked-by: Len Brown
Signed-off-by: Jiri Kosina
13 Jun, 2011
1 commit
-
Change all "arch/i386" to "arch/x86" in Documentaion/,
since the directory has changed.Also update the files which have changed their filename
in the meantime accordingly.Signed-off-by: Wanlong Gao
[jkosina@suse.cz: reword changelog]
Signed-off-by: Jiri Kosina
17 Mar, 2011
1 commit
-
Update cpufreq governor documentation for sampling_down_factor tunable
parameter.Signed-off-by: Vishwanath BS
Signed-off-by: Dave Jones