From nobody Sat Feb 7 17:55:52 2026 Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 189502882B6 for ; Sat, 1 Nov 2025 05:56:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761976602; cv=none; b=ZbRnthdoKn3K+ROrdwBvVjEOO8Rx2SyJLD3lYXg3Q7PdGrjJbq3FASOtQr3YbU07EIFauGRILLPQ2Nff0rC8vX2r2imECGvIgoUvKoeu+qcFBnqJDL5sGDOtv8Z3lDwjZ+vmDyzNFqvLBA4cE08WkUh8Avx324kVFfSwU55HXOc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761976602; c=relaxed/simple; bh=ciqXU+1NcuVr4iigJo4KYFshbbWaXN1fMRAm85K4jo8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=RWazhHT6sro3yDUixO2gQfyvinYYMWctZE1ak6mSNMMnJRuSz88QDk/uPGnbP1oBQ/OZ4lcwILS4gBaYSCHCRCLKkJ+3u215UUpCQMUS/nWv2AUSmsYKCO24Q0GIPrHp3h12zGg45i6ke8i8KARp1dGjAWrZQkzkRccbWO7gz8Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=e6KA+W9V; arc=none smtp.client-ip=209.85.222.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="e6KA+W9V" Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-890521c116fso294140185a.3 for ; Fri, 31 Oct 2025 22:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761976599; x=1762581399; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=cRCZltpC3RV67ZWRzBd3H/sPBTtda5yz34HGDlmtPjs=; b=e6KA+W9V931lxF4l6UbnyH1SGU1QpYowTIK/a6/OG//mboqQtUwoIJUOpbjOp3qQIr eq7J4G/ju6fIicJnEk/LWIGMNgzWJl1a2tHvMUg1hnXI3rVrK2/HlzbyC0ofFUTt8WNd EANidwJjFg8/KN6yrVbEn7sZZzxoOsjxNKj2QVQ9JzsD2ExpA3l8RRASt8ThnsdkWCZB rrIAlcFSibMyh6DD/xKcP9+YHGHiU+xjCAgHiD8mCoEY04gctVHZL0zObrAAVMu3BGeE CpcG/w4hfRBkGQQobHZ5tj0bgir1lAmdqx3UQYgbS8Ig1acAPde/Bt30CY/+LXRplxOi K4Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761976599; x=1762581399; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cRCZltpC3RV67ZWRzBd3H/sPBTtda5yz34HGDlmtPjs=; b=g9aSszFm+CR5QfehTWCC+kKgJDhH5a/LqXbi0SCrwzTwcGFOVVOW5DKC5aRnYeHNlM qJ+JvXOKpueZBip2rEsi/WhrNwSX1nSnl1aFQEQIEhxSaNU4mlgZfC8iDG77ZRR9KjZ3 TirJAc38O4jqNOPvAZw7Ed9xdQuvivr3RbSkwliSqiN1ggoZNxl4C9NJPgbNDQPk0MFF W/FsR8NzAx/oSMqlVkfIc3TbfeyYpKSRpUF0qBFMLQ6RN8B/LpS/o9+Wru9ReBmV3vXe yGgR0bSQFHlDZWkiIpqF6vzUWTT0niNpnQdDCfLRSHj71GHsxfaH7iLapz9h/bHTRU1X U6Yw== X-Gm-Message-State: AOJu0YxC+mm2G3qREuu+fU44lA+/1DJP1PBjxg4Q2RS5Hj2BYeAAr8fT i0zYNynTzI/wmjwQsqNd9xThU/bCP2bam/zfX3+QSR2m/M99LDIsfkU4KByX4WUxMyc= X-Gm-Gg: ASbGncsUevS4IbB2U5pX2QODb8kyeuctEW+D0CxVs2M0WNfXUR2cqwhaHlmpEVK321u NiEJe1iazkhCKH3KID9+ZpA9Fq2CGxyMRHQ/01FJ7UnYkOGaZwCtKJhukGuxOmTi05OwcC4yhEJ 1ke1wF5HriXIYy7Cw/+tUUDEkxoPvUu4Isk7phQj+R9kYXgKJm8E1VJSkBJ0uAUd/WXPC09MjpA Utlcowl0sbz6IPdCZ0MUUfJDdjijeUNxHKHbEqPpjPv5L5SD02vtOEjzNa4uaLNBnk8HPFUmOAr wRf1EedmmSxNfrJwhCkseuGlb3o1HYBQNYp+U7b05n/eUx33axQIyqvfod1SvrKXHccH/Q1B1NH tRyPUbHZVGXwWzozWJs2Q4cducnBrhCQIIphSe+lWuSN1k3yffB2jo8fPTR5akuQxRNjE3ziL0v ew X-Google-Smtp-Source: AGHT+IHc0zrGSwszyLR24bRSf09Tu7kSTOa11Mr2wBs5EV0LlCeYsUd+vTRKfV7uXA70Z5R/dSJUTw== X-Received: by 2002:a05:620a:700d:b0:85c:bb2:ad8c with SMTP id af79cd13be357-8ab9b59957emr747008785a.74.1761976598533; Fri, 31 Oct 2025 22:56:38 -0700 (PDT) Received: from archie.me ([210.87.74.117]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8ac0357f7desm247195085a.41.2025.10.31.22.56.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Oct 2025 22:56:37 -0700 (PDT) Received: by archie.me (Postfix, from userid 1000) id EF0004209E50; Sat, 01 Nov 2025 12:56:25 +0700 (WIB) From: Bagas Sanjaya To: Linux Kernel Mailing List , Linux Documentation , Linux Power Management Cc: "Rafael J. Wysocki" , Viresh Kumar , Jonathan Corbet , Bagas Sanjaya Subject: [PATCH] Documentation: intel-pstate: Use :ref: directive for internal linking Date: Sat, 1 Nov 2025 12:56:14 +0700 Message-ID: <20251101055614.32270-1-bagasdotme@gmail.com> X-Mailer: git-send-email 2.51.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=19443; i=bagasdotme@gmail.com; h=from:subject; bh=ciqXU+1NcuVr4iigJo4KYFshbbWaXN1fMRAm85K4jo8=; b=owGbwMvMwCX2bWenZ2ig32LG02pJDJmsCwr/T7+j+OREpvLzGbKiPadX7evzuMQTa1o21fb2u aX3AiYFdpSyMIhxMciKKbJMSuRrOr3LSORC+1pHmDmsTCBDGLg4BWAiU/kYfjImPrp05v/deZUO Lw3WrxKczKt3Ldxi2tp7pscPChuITIliZLhR+TDOatIpq6lCj1prDEX2aPuapfxk//Zkrq+Yrvb lQ1wA X-Developer-Key: i=bagasdotme@gmail.com; a=openpgp; fpr=701B806FDCA5D3A58FFB8F7D7C276C64A5E44A1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" pstate docs uses standard reST construct (`Section title`_) for cross-referencing sections (internal linking), rather than for external links. Incorrect cross-references are not caught when these are written in that syntax, however (fortunately docutils 0.22 raise duplicate target warnings that get fixed in cb908f8b0acc7e ("Documentation: intel_pstate: fix duplicate hyperlink target errors")). Convert the cross-references to use :ref: directive, which doesn't exhibit this problem. Signed-off-by: Bagas Sanjaya Reviewed-by: Randy Dunlap Tested-by: Randy Dunlap --- Documentation/admin-guide/pm/intel_pstate.rst | 133 +++++++++--------- 1 file changed, 70 insertions(+), 63 deletions(-) diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/= admin-guide/pm/intel_pstate.rst index 9cdd9dad651698..fde967b0c2e0e5 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -48,8 +48,9 @@ only way to pass early-configuration-time parameters to i= t is via the kernel command line. However, its configuration can be adjusted via ``sysfs`` to= a great extent. In some configurations it even is possible to unregister it= via ``sysfs`` which allows another ``CPUFreq`` scaling driver to be loaded and -registered (see `below `_). +registered (see :ref:`below `). =20 +.. _operation_modes: =20 Operation Modes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@ -62,7 +63,7 @@ a certain performance scaling algorithm. Which of them w= ill be in effect depends on what kernel command line options are used and on the capabiliti= es of the processor. =20 -.. _Active Mode: +.. _active_mode: =20 Active Mode ----------- @@ -96,7 +97,7 @@ Which of the P-state selection algorithms is used by defa= ult depends on the Namely, if that option is set, the ``performance`` algorithm will be used = by default, and the other one will be used by default if it is not set. =20 -.. _Active Mode With HWP: +.. _active_mode_hwp: =20 Active Mode With HWP ~~~~~~~~~~~~~~~~~~~~ @@ -127,7 +128,7 @@ Energy-Performance Bias (EPB) knob (otherwise), which m= eans that the processor's internal P-state selection logic is expected to focus entirely on performa= nce. =20 This will override the EPP/EPB setting coming from the ``sysfs`` interface -(see `Energy vs Performance Hints`_ below). Moreover, any attempts to cha= nge +(see :ref:`energy_performance_hints` below). Moreover, any attempts to ch= ange the EPP/EPB to a value different from 0 ("performance") via ``sysfs`` in t= his configuration will be rejected. =20 @@ -196,7 +197,7 @@ This is the default P-state selection algorithm if the :c:macro:`CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE` kernel configuration op= tion is not set. =20 -.. _Passive Mode: +.. _passive_mode: =20 Passive Mode ------------ @@ -295,12 +296,12 @@ Unlike ``_PSS`` objects in the ACPI tables, ``intel_p= state`` always exposes the entire range of available P-states, including the whole turbo range, t= o the ``CPUFreq`` core and (in the passive mode) to generic scaling governors. = This generally causes turbo P-states to be set more often when ``intel_pstate``= is -used relative to ACPI-based CPU performance scaling (see `below `_ -for more information). +used relative to ACPI-based CPU performance scaling (see +:ref:`below ` for more information). =20 Moreover, since ``intel_pstate`` always knows what the real turbo threshol= d is (even if the Configurable TDP feature is enabled in the processor), its -``no_turbo`` attribute in ``sysfs`` (described `below `_) = should +``no_turbo`` attribute in ``sysfs`` (described :ref:`below = `) should work as expected in all cases (that is, if set to disable turbo P-states, = it always should prevent ``intel_pstate`` from using them). =20 @@ -313,12 +314,12 @@ pieces of information on it to be known, including: =20 * The minimum supported P-state. =20 - * The maximum supported `non-turbo P-state `_. + * The maximum supported :ref:`non-turbo P-state `. =20 * Whether or not turbo P-states are supported at all. =20 - * The maximum supported `one-core turbo P-state `_ (if turbo P-st= ates - are supported). + * The maximum supported :ref:`one-core turbo P-state ` (if turbo + P-states are supported). =20 * The scaling formula to translate the driver's internal representation of P-states into frequencies and the other way around. @@ -406,10 +407,10 @@ Energy-Aware Scheduling Support =20 If ``CONFIG_ENERGY_MODEL`` has been set during kernel configuration and ``intel_pstate`` runs on a hybrid processor without SMT, in addition to en= abling -`CAS `_ it registers an Energy Model for the processor. This allows= the +:ref:`CAS` it registers an Energy Model for the processor. This allows the Energy-Aware Scheduling (EAS) support to be enabled in the CPU scheduler if ``schedutil`` is used as the ``CPUFreq`` governor which requires ``intel_= pstate`` -to operate in the `passive mode `_. +to operate in the :ref:`passive mode `. =20 The Energy Model registered by ``intel_pstate`` is artificial (that is, it= is based on abstract cost values and it does not include any real power numbe= rs) @@ -438,7 +439,7 @@ the ``energy_model`` directory in ``debugfs`` (typlical= ly mounted on User Space Interface in ``sysfs`` =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -.. _Global Attributes: +.. _global_attributes: =20 Global Attributes ----------------- @@ -452,8 +453,8 @@ argument is passed to the kernel in the command line. =20 ``max_perf_pct`` Maximum P-state the driver is allowed to set in percent of the - maximum supported performance level (the highest supported `turbo - P-state `_). + maximum supported performance level (the highest supported :ref:`turbo + P-state `). =20 This attribute will not be exposed if the ``intel_pstate=3Dper_cpu_perf_limits`` argument is present in the kernel @@ -461,8 +462,8 @@ argument is passed to the kernel in the command line. =20 ``min_perf_pct`` Minimum P-state the driver is allowed to set in percent of the - maximum supported performance level (the highest supported `turbo - P-state `_). + maximum supported performance level (the highest supported :ref:`turbo + P-state `). =20 This attribute will not be exposed if the ``intel_pstate=3Dper_cpu_perf_limits`` argument is present in the kernel @@ -471,18 +472,18 @@ argument is passed to the kernel in the command line. ``num_pstates`` Number of P-states supported by the processor (between 0 and 255 inclusive) including both turbo and non-turbo P-states (see - `Turbo P-states Support`_). + :ref:`turbo`). =20 This attribute is present only if the value exposed by it is the same for all of the CPUs in the system. =20 The value of this attribute is not affected by the ``no_turbo`` - setting described `below `_. + setting described :ref:`below `. =20 This attribute is read-only. =20 ``turbo_pct`` - Ratio of the `turbo range `_ size to the size of the entire + Ratio of the :ref:`turbo range ` size to the size of the entire range of supported P-states, in percent. =20 This attribute is present only if the value exposed by it is the same @@ -494,7 +495,7 @@ argument is passed to the kernel in the command line. =20 ``no_turbo`` If set (equal to 1), the driver is not allowed to set any turbo P-states - (see `Turbo P-states Support`_). If unset (equal to 0, which is the + (see :ref:`turbo`). If unset (equal to 0, which is the default), turbo P-states can be set by the driver. [Note that ``intel_pstate`` does not support the general ``boost`` attribute (supported by some other scaling drivers) which is replaced @@ -503,11 +504,11 @@ argument is passed to the kernel in the command line. This attribute does not affect the maximum supported frequency value supplied to the ``CPUFreq`` core and exposed via the policy interface, but it affects the maximum possible value of per-policy P-state limits - (see `Interpretation of Policy Attributes`_ below for details). + (see :ref:`policy_attributes_interpretation` below for details). =20 ``hwp_dynamic_boost`` This attribute is only present if ``intel_pstate`` works in the - `active mode with the HWP feature enabled `_ in + :ref:`active mode with the HWP feature enabled ` in the processor. If set (equal to 1), it causes the minimum P-state limit to be increased dynamically for a short time whenever a task previously waiting on I/O is selected to run on a given logical CPU (the purpose @@ -522,12 +523,12 @@ argument is passed to the kernel in the command line. Operation mode of the driver: "active", "passive" or "off". =20 "active" - The driver is functional and in the `active mode - `_. + The driver is functional and in the :ref:`active mode + `. =20 "passive" - The driver is functional and in the `passive mode - `_. + The driver is functional and in the :ref:`passive mode + `. =20 "off" The driver is not functional (it is not registered as a scaling @@ -555,13 +556,15 @@ argument is passed to the kernel in the command line. attribute to "1" enables the energy-efficiency optimizations and setting to "0" disables them. =20 +.. _policy_attributes_interpretation: + Interpretation of Policy Attributes ----------------------------------- =20 The interpretation of some ``CPUFreq`` policy attributes described in Documentation/admin-guide/pm/cpufreq.rst is special with ``intel_pstate`` as the current scaling driver and it generally depends on the driver's -`operation mode `_. +:ref:`operation mode `. =20 First of all, the values of the ``cpuinfo_max_freq``, ``cpuinfo_min_freq``= and ``scaling_cur_freq`` attributes are produced by applying a processor-speci= fic @@ -570,9 +573,10 @@ Also, the values of the ``scaling_max_freq`` and ``sca= ling_min_freq`` attributes are capped by the frequency corresponding to the maximum P-stat= e that the driver is allowed to set. =20 -If the ``no_turbo`` `global attribute `_ is set, the drive= r is -not allowed to use turbo P-states, so the maximum value of ``scaling_max_f= req`` -and ``scaling_min_freq`` is limited to the maximum non-turbo P-state frequ= ency. +If the ``no_turbo`` :ref:`global attribute ` is set, the dr= iver +is not allowed to use turbo P-states, so the maximum value of +``scaling_max_freq`` and ``scaling_min_freq`` is limited to the maximum +non-turbo P-state frequency. Accordingly, setting ``no_turbo`` causes ``scaling_max_freq`` and ``scaling_min_freq`` to go down to that value if they were above it before. However, the old values of ``scaling_max_freq`` and ``scaling_min_freq`` w= ill be @@ -584,7 +588,7 @@ and ``scaling_min_freq`` corresponds to the maximum sup= ported turbo P-state, which also is the value of ``cpuinfo_max_freq`` in either case. =20 Next, the following policy attributes have special meaning if -``intel_pstate`` works in the `active mode `_: +``intel_pstate`` works in the :ref:`active mode `: =20 ``scaling_available_governors`` List of P-state selection algorithms provided by ``intel_pstate``. @@ -605,20 +609,22 @@ processor: Shows the base frequency of the CPU. Any frequency above this will be in the turbo frequency range. =20 -The meaning of these attributes in the `passive mode `_ is = the +The meaning of these attributes in the :ref:`passive mode ` = is the same as for other scaling drivers. =20 Additionally, the value of the ``scaling_driver`` attribute for ``intel_ps= tate`` depends on the operation mode of the driver. Namely, it is either -"intel_pstate" (in the `active mode `_) or "intel_cpufreq" (= in the -`passive mode `_). +"intel_pstate" (in the :ref:`active mode `) or "intel_cpufreq" +(in the :ref:`passive mode `). + +.. _pstate_limits_coordination: =20 Coordination of P-State Limits ------------------------------ =20 ``intel_pstate`` allows P-state limits to be set in two ways: with the hel= p of -the ``max_perf_pct`` and ``min_perf_pct`` `global attributes -`_ or via the ``scaling_max_freq`` and ``scaling_min_f= req`` +the ``max_perf_pct`` and ``min_perf_pct`` :ref:`global attributes +` or via the ``scaling_max_freq`` and ``scaling_min_fre= q`` ``CPUFreq`` policy attributes. The coordination between those limits is b= ased on the following rules, regardless of the current operation mode of the dr= iver: =20 @@ -640,17 +646,18 @@ on the following rules, regardless of the current ope= ration mode of the driver: =20 3. The global and per-policy limits can be set independently. =20 -In the `active mode with the HWP feature enabled `_= , the +In the :ref:`active mode with the HWP feature enabled `, = the resulting effective values are written into hardware registers whenever the limits change in order to request its internal P-state selection logic to = always set P-states within these limits. Otherwise, the limits are taken into ac= count -by scaling governors (in the `passive mode `_) and by the d= river -every time before setting a new P-state for a CPU. +by scaling governors (in the :ref:`passive mode `) and by the +driver every time before setting a new P-state for a CPU. =20 Additionally, if the ``intel_pstate=3Dper_cpu_perf_limits`` command line a= rgument is passed to the kernel, ``max_perf_pct`` and ``min_perf_pct`` are not exp= osed at all and the only way to set the limits is by using the policy attribute= s. =20 +.. _energy_performance_hints: =20 Energy vs Performance Hints --------------------------- @@ -710,9 +717,9 @@ output. On those systems each ``_PSS`` object returns a list of P-states supported= by the corresponding CPU which basically is a subset of the P-states range th= at can be used by ``intel_pstate`` on the same system, with one exception: the wh= ole -`turbo range `_ is represented by one item in it (the topmost one)= . By -convention, the frequency returned by ``_PSS`` for that item is greater by= 1 MHz -than the frequency of the highest non-turbo P-state listed by it, but the +:ref:`turbo range ` is represented by one item in it (the topmost o= ne). +By convention, the frequency returned by ``_PSS`` for that item is greater= by +1 MHz than the frequency of the highest non-turbo P-state listed by it, bu= t the corresponding P-state representation (following the hardware specification) returned for it matches the maximum supported turbo P-state (or is the special value 255 meaning essentially "go as high as you can get"). @@ -738,18 +745,18 @@ benefit from running at turbo frequencies will be giv= en non-turbo P-states instead. =20 One more issue related to that may appear on systems supporting the -`Configurable TDP feature `_ allowing the platform firmware to set= the -turbo threshold. Namely, if that is not coordinated with the lists of P-s= tates -returned by ``_PSS`` properly, there may be more than one item correspondi= ng to -a turbo P-state in those lists and there may be a problem with avoiding the -turbo range (if desirable or necessary). Usually, to avoid using turbo -P-states overall, ``acpi-cpufreq`` simply avoids using the topmost state l= isted -by ``_PSS``, but that is not sufficient when there are other turbo P-state= s in -the list returned by it. +:ref:`Configurable TDP feature ` allowing the platform firmware to = set +the turbo threshold. Namely, if that is not coordinated with the lists of +P-states returned by ``_PSS`` properly, there may be more than one item +corresponding to a turbo P-state in those lists and there may be a problem= with +avoiding the turbo range (if desirable or necessary). Usually, to avoid u= sing +turbo P-states overall, ``acpi-cpufreq`` simply avoids using the topmost s= tate +listed by ``_PSS``, but that is not sufficient when there are other turbo +P-states in the list returned by it. =20 Apart from the above, ``acpi-cpufreq`` works like ``intel_pstate`` in the -`passive mode `_, except that the number of P-states it can= set -is limited to the ones listed by the ACPI ``_PSS`` objects. +:ref:`passive mode `, except that the number of P-states it = can +set is limited to the ones listed by the ACPI ``_PSS`` objects. =20 =20 Kernel Command Line Options for ``intel_pstate`` @@ -764,11 +771,11 @@ of them have to be prepended with the ``intel_pstate= =3D`` prefix. processor is supported by it. =20 ``active`` - Register ``intel_pstate`` in the `active mode `_ to start - with. + Register ``intel_pstate`` in the :ref:`active mode ` to + start with. =20 ``passive`` - Register ``intel_pstate`` in the `passive mode `_ to + Register ``intel_pstate`` in the :ref:`passive mode ` to start with. =20 ``force`` @@ -801,12 +808,12 @@ of them have to be prepended with the ``intel_pstate= =3D`` prefix. and this option has no effect. =20 ``per_cpu_perf_limits`` - Use per-logical-CPU P-State limits (see `Coordination of P-state - Limits`_ for details). + Use per-logical-CPU P-State limits (see + :ref:`pstate_limits_coordination` for details). =20 ``no_cas`` - Do not enable `capacity-aware scheduling `_ which is enabled by - default on hybrid systems without SMT. + Do not enable :ref:`capacity-aware scheduling ` which is enabled + by default on hybrid systems without SMT. =20 Diagnostics and Tuning =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@ -818,7 +825,7 @@ There are two static trace events that can be used for = ``intel_pstate`` diagnostics. One of them is the ``cpu_frequency`` trace event generally u= sed by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event spe= cific to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only = if -it works in the `active mode `_. +it works in the :ref:`active mode `. =20 The following sequence of shell commands can be used to enable them and see their output (if the kernel is generally configured to support event traci= ng):: @@ -830,7 +837,7 @@ their output (if the kernel is generally configured to = support event tracing):: gnome-terminal--4510 [001] ..s. 1177.680733: pstate_sample: core_busy= =3D107 scaled=3D94 from=3D26 to=3D26 mperf=3D1143818 aperf=3D1230607 tsc=3D= 29838618 freq=3D2474476 cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=3D2900000 cpu_id= =3D2 =20 -If ``intel_pstate`` works in the `passive mode `_, the +If ``intel_pstate`` works in the :ref:`passive mode `, the ``cpu_frequency`` trace event will be triggered either by the ``schedutil`` scaling governor (for the policies it is attached to), or by the ``CPUFreq= `` core (for the policies with other scaling governors). base-commit: eda819ce75b976da206c2c605d380a881e9281b1 --=20 An old man doll... just what I always wanted! - Clara