From patchwork Fri Jan 6 05:38:04 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 90106 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp9302647qgi; Thu, 5 Jan 2017 21:38:54 -0800 (PST) X-Received: by 10.84.135.34 with SMTP id 31mr141948376pli.50.1483681134455; Thu, 05 Jan 2017 21:38:54 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m2si44035572plk.334.2017.01.05.21.38.54; Thu, 05 Jan 2017 21:38:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-pm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754725AbdAFFiU (ORCPT + 13 others); Fri, 6 Jan 2017 00:38:20 -0500 Received: from mail-pg0-f54.google.com ([74.125.83.54]:33260 "EHLO mail-pg0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754501AbdAFFiS (ORCPT ); Fri, 6 Jan 2017 00:38:18 -0500 Received: by mail-pg0-f54.google.com with SMTP id g1so209273914pgn.0 for ; Thu, 05 Jan 2017 21:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=BOF5j6d6P2duAwG2Y2TNmiG9G0qmOex8EvDjQSl/+nw=; b=TIA1/i4FBMLpFMcc8X3fBgox0qwZYXbptIVgXRQfZ1xnqgoJSFoIYk6w7+wTefExNu OulNKjelmf17RUaVrybpWxKa6kCgbL1Nz2n2QpF4uWmaa9gZjGGXAGFzgvUfDSEKIfuW iYCqreKmipTaEORxvLC2hWEFxPbdKxktDStx8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=BOF5j6d6P2duAwG2Y2TNmiG9G0qmOex8EvDjQSl/+nw=; b=MwyPOC0bS+Qfv1P42LXDfX4+N70Srz11uy0MMcJvkLrvCA4bttlnizj0qqkIrnkaYJ dJlE2+6lrnTxfPW69cyk+77xNNtt/uGtOIcw7saHowml6X2swwe+RVRajGZCEnnV6VMY jSccVT/nNGkrrpOb30C3ziAbh/RKA3d+WVLGmCa/2IWviqStDIHc0BFMqnHbb0GBKmVR M0mrhdsMid7m/OZoQJp/tjgbtYDmzhYZ6e7I8jCu/F3FJT0kkZmEhDLZOlhboE1s+58+ +56BSRXUUWob7DPQtqkURf1LFvcu583J7JE4r427Fd13d56o3uK2YI+MO4WdKj5esZoj 1sRQ== X-Gm-Message-State: AIkVDXJBZLov5sV2u7HsF7yI3X+YMnedFVqh219QTEkXaDepmY2tmpJBfcThTDi1GAmr0u9A X-Received: by 10.84.136.1 with SMTP id 1mr164874382plk.152.1483681097471; Thu, 05 Jan 2017 21:38:17 -0800 (PST) Received: from localhost ([122.171.77.55]) by smtp.gmail.com with ESMTPSA id f3sm80892721pga.1.2017.01.05.21.38.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 21:38:16 -0800 (PST) From: Viresh Kumar To: Rafael Wysocki , Viresh Kumar Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , Claudio Scordino , linux-doc@vger.kernel.org Subject: [PATCH 1/2] cpufreq: Documentation: Minor reformatting Date: Fri, 6 Jan 2017 11:08:04 +0530 Message-Id: X-Mailer: git-send-email 2.7.1.410.g6faf27b Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org This patch doesn't change the content of the documentation, but rather reformat it to make it more readable. Signed-off-by: Viresh Kumar --- Documentation/cpu-freq/governors.txt | 205 +++++++++++++++++++---------------- 1 file changed, 112 insertions(+), 93 deletions(-) -- 2.7.1.410.g6faf27b -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index c15aa75f5227..63eef4cca1b7 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt @@ -111,82 +111,96 @@ directory. The CPUfreq governor "ondemand" sets the CPU depending on the current usage. To do this the CPU must have the capability to -switch the frequency very quickly. There are a number of sysfs file -accessible parameters: - -sampling_rate: measured in uS (10^-6 seconds), this is how often you -want the kernel to look at the CPU usage and to make decisions on -what to do about the frequency. Typically this is set to values of -around '10000' or more. It's default value is (cmp. with users-guide.txt): -transition_latency * 1000 -Be aware that transition latency is in ns and sampling_rate is in us, so you -get the same sysfs value by default. -Sampling rate should always get adjusted considering the transition latency -To set the sampling rate 750 times as high as the transition latency -in the bash (as said, 1000 is default), do: -echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) \ - >ondemand/sampling_rate - -sampling_rate_min: -The sampling rate is limited by the HW transition latency: -transition_latency * 100 -Or by kernel restrictions: -If CONFIG_NO_HZ_COMMON is set, the limit is 10ms fixed. -If CONFIG_NO_HZ_COMMON is not set or nohz=off boot parameter is used, the -limits depend on the CONFIG_HZ option: -HZ=1000: min=20000us (20ms) -HZ=250: min=80000us (80ms) -HZ=100: min=200000us (200ms) -The highest value of kernel and HW latency restrictions is shown and -used as the minimum sampling rate. - -up_threshold: defines what the average CPU usage between the samplings -of 'sampling_rate' needs to be for the kernel to make a decision on -whether it should increase the frequency. For example when it is set -to its default value of '95' it means that between the checking -intervals the CPU needs to be on average more than 95% in use to then -decide that the CPU frequency needs to be increased. - -ignore_nice_load: this parameter takes a value of '0' or '1'. When -set to '0' (its default), all processes are counted towards the -'cpu utilisation' value. When set to '1', the processes that are -run with a 'nice' value will not count (and thus be ignored) in the -overall usage calculation. This is useful if you are running a CPU -intensive calculation on your laptop that you do not care how long it -takes to complete as you can 'nice' it and prevent it from taking part -in the deciding process of whether to increase your CPU frequency. - -sampling_down_factor: this parameter controls the rate at which the -kernel makes a decision on when to decrease the frequency while running -at top speed. When set to 1 (the default) decisions to reevaluate load -are made at the same interval regardless of current clock speed. But -when 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. - -powersave_bias: this parameter takes a value between 0 to 1000. It -defines the percentage (times 10) value of the target frequency that -will be shaved off of the target. For example, when set to 100 -- 10%, -when ondemand governor would have targeted 1000 MHz, it will target -1000 MHz - (10% of 1000 MHz) = 900 MHz instead. This is set to 0 -(disabled) by default. -When AMD frequency sensitivity powersave bias driver -- -drivers/cpufreq/amd_freq_sensitivity.c is loaded, this parameter -defines the workload frequency sensitivity threshold in which a lower -frequency is chosen instead of ondemand governor's original target. -The frequency sensitivity is a hardware reported (on AMD Family 16h -Processors and above) value between 0 to 100% that tells software how -the performance of the workload running on a CPU will change when -frequency changes. A workload with sensitivity of 0% (memory/IO-bound) -will not perform any better on higher core frequency, whereas a -workload with sensitivity of 100% (CPU-bound) will perform better -higher the frequency. When the driver is loaded, this is set to 400 -by default -- for CPUs running workloads with sensitivity value below -40%, a lower frequency is chosen. Unloading the driver or writing 0 -will disable this feature. +switch the frequency very quickly. + +Sysfs files: + +* sampling_rate: + + Measured in uS (10^-6 seconds), this is how often you want the kernel + to look at the CPU usage and to make decisions on what to do about the + frequency. Typically this is set to values of around '10000' or more. + It's default value is (cmp. with users-guide.txt): transition_latency + * 1000. Be aware that transition latency is in ns and sampling_rate + is in us, so you get the same sysfs value by default. Sampling rate + should always get adjusted considering the transition latency to set + the sampling rate 750 times as high as the transition latency in the + bash (as said, 1000 is default), do: + + $ echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate + +* sampling_rate_min: + + The sampling rate is limited by the HW transition latency: + transition_latency * 100 + + Or by kernel restrictions: + - If CONFIG_NO_HZ_COMMON is set, the limit is 10ms fixed. + - If CONFIG_NO_HZ_COMMON is not set or nohz=off boot parameter is + used, the limits depend on the CONFIG_HZ option: + HZ=1000: min=20000us (20ms) + HZ=250: min=80000us (80ms) + HZ=100: min=200000us (200ms) + + The highest value of kernel and HW latency restrictions is shown and + used as the minimum sampling rate. + +* up_threshold: + + This defines what the average CPU usage between the samplings of + 'sampling_rate' needs to be for the kernel to make a decision on + whether it should increase the frequency. For example when it is set + to its default value of '95' it means that between the checking + intervals the CPU needs to be on average more than 95% in use to then + decide that the CPU frequency needs to be increased. + +* ignore_nice_load: + + This parameter takes a value of '0' or '1'. When set to '0' (its + default), all processes are counted towards the 'cpu utilisation' + value. When set to '1', the processes that are run with a 'nice' + value will not count (and thus be ignored) in the overall usage + calculation. This is useful if you are running a CPU intensive + calculation on your laptop that you do not care how long it takes to + complete as you can 'nice' it and prevent it from taking part in the + deciding process of whether to increase your CPU frequency. + +* sampling_down_factor: + + This parameter controls the rate at which the kernel makes a decision + on when to decrease the frequency while running at top speed. When set + to 1 (the default) decisions to reevaluate load are made at the same + interval regardless of current clock speed. But when 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. + +* powersave_bias: + + This parameter takes a value between 0 to 1000. It defines the + percentage (times 10) value of the target frequency that will be + shaved off of the target. For example, when set to 100 -- 10%, when + ondemand governor would have targeted 1000 MHz, it will target + 1000 MHz - (10% of 1000 MHz) = 900 MHz instead. This is set to 0 + (disabled) by default. + + When AMD frequency sensitivity powersave bias driver -- + drivers/cpufreq/amd_freq_sensitivity.c is loaded, this parameter + defines the workload frequency sensitivity threshold in which a lower + frequency is chosen instead of ondemand governor's original target. + The frequency sensitivity is a hardware reported (on AMD Family 16h + Processors and above) value between 0 to 100% that tells software how + the performance of the workload running on a CPU will change when + frequency changes. A workload with sensitivity of 0% (memory/IO-bound) + will not perform any better on higher core frequency, whereas a + workload with sensitivity of 100% (CPU-bound) will perform better + higher the frequency. When the driver is loaded, this is set to 400 by + default -- for CPUs running workloads with sensitivity value below + 40%, a lower frequency is chosen. Unloading the driver or writing 0 + will disable this feature. 2.5 Conservative @@ -200,23 +214,28 @@ CPU. This behaviour more suitable in a battery powered environment. The governor is tweaked in the same manner as the "ondemand" governor through sysfs with the addition of: -freq_step: this describes what percentage steps the cpu freq should be -increased and decreased smoothly by. By default the cpu frequency will -increase in 5% chunks of your maximum cpu frequency. You can change this -value to anywhere between 0 and 100 where '0' will effectively lock your -CPU at a speed regardless of its load whilst '100' will, in theory, make -it behave identically to the "ondemand" governor. - -down_threshold: same as the 'up_threshold' found for the "ondemand" -governor but for the opposite direction. For example when set to its -default value of '20' it means that if the CPU usage needs to be below -20% between samples to have the frequency decreased. - -sampling_down_factor: similar functionality as in "ondemand" governor. -But in "conservative", it controls the rate at which the kernel makes -a decision on when to decrease the frequency while running in any -speed. Load for frequency increase is still evaluated every -sampling rate. +* freq_step: + + This describes what percentage steps the cpu freq should be increased + and decreased smoothly by. By default the cpu frequency will increase + in 5% chunks of your maximum cpu frequency. You can change this value + to anywhere between 0 and 100 where '0' will effectively lock your CPU + at a speed regardless of its load whilst '100' will, in theory, make + it behave identically to the "ondemand" governor. + +* down_threshold: + + Same as the 'up_threshold' found for the "ondemand" governor but for + the opposite direction. For example when set to its default value of + '20' it means that if the CPU usage needs to be below 20% between + samples to have the frequency decreased. + +* sampling_down_factor: + + Similar functionality as in "ondemand" governor. But in + "conservative", it controls the rate at which the kernel makes a + decision on when to decrease the frequency while running in any speed. + Load for frequency increase is still evaluated every sampling rate. 3. The Governor Interface in the CPUfreq Core =============================================