Merge tag 'docs-6.3' of git://git.lwn.net/linux
authorLinus Torvalds <torvalds@linux-foundation.org>
Wed, 22 Feb 2023 20:00:20 +0000 (12:00 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Wed, 22 Feb 2023 20:00:20 +0000 (12:00 -0800)
Pull documentation updates from Jonathan Corbet:
 "It has been a moderately calm cycle for documentation; the significant
  changes include:

   - Some significant additions to the memory-management documentation

   - Some improvements to navigation in the HTML-rendered docs

   - More Spanish and Chinese translations

  ... and the usual set of typo fixes and such"

* tag 'docs-6.3' of git://git.lwn.net/linux: (68 commits)
  Documentation/watchdog/hpwdt: Fix Format
  Documentation/watchdog/hpwdt: Fix Reference
  Documentation: core-api: padata: correct spelling
  docs/mm: Physical Memory: correct spelling in reference to CONFIG_PAGE_EXTENSION
  docs: Use HTML comments for the kernel-toc SPDX line
  docs: Add more information to the HTML sidebar
  Documentation: KVM: Update AMD memory encryption link
  printk: Document that CONFIG_BOOT_PRINTK_DELAY required for boot_delay=
  Documentation: userspace-api: correct spelling
  Documentation: sparc: correct spelling
  Documentation: driver-api: correct spelling
  Documentation: admin-guide: correct spelling
  docs: add workload-tracing document to admin-guide
  docs/admin-guide/mm: remove useless markup
  docs/mm: remove useless markup
  docs/mm: Physical Memory: remove useless markup
  docs/sp_SP: Add process magic-number translation
  docs: ftrace: always use canonical ftrace path
  Doc/damon: fix the data path error
  dma-buf: Add "dma-buf" to title of documentation
  ...

16 files changed:
1  2 
Documentation/admin-guide/cgroup-v2.rst
Documentation/admin-guide/index.rst
Documentation/admin-guide/kernel-parameters.txt
Documentation/admin-guide/mm/zswap.rst
Documentation/admin-guide/pm/amd-pstate.rst
Documentation/admin-guide/thermal/intel_powerclamp.rst
Documentation/conf.py
Documentation/driver-api/pin-control.rst
Documentation/driver-api/surface_aggregator/ssh.rst
Documentation/hid/intel-ish-hid.rst
Documentation/hwmon/index.rst
Documentation/networking/device_drivers/ethernet/mellanox/mlx5/tracepoints.rst
Documentation/scheduler/index.rst
Documentation/sound/hd-audio/notes.rst
Documentation/x86/resctrl.rst
lib/Kconfig.debug

Simple merge
index 3ce9604,0000000..08509b9
mode 100644,000000..100644
--- /dev/null
@@@ -1,345 -1,0 +1,345 @@@
- scheme to work for both preemptable and non-preemptable kernels.
 +=======================
 +Intel Powerclamp Driver
 +=======================
 +
 +By:
 +  - Arjan van de Ven <arjan@linux.intel.com>
 +  - Jacob Pan <jacob.jun.pan@linux.intel.com>
 +
 +.. Contents:
 +
 +      (*) Introduction
 +          - Goals and Objectives
 +
 +      (*) Theory of Operation
 +          - Idle Injection
 +          - Calibration
 +
 +      (*) Performance Analysis
 +          - Effectiveness and Limitations
 +          - Power vs Performance
 +          - Scalability
 +          - Calibration
 +          - Comparison with Alternative Techniques
 +
 +      (*) Usage and Interfaces
 +          - Generic Thermal Layer (sysfs)
 +          - Kernel APIs (TBD)
 +
 +      (*) Module Parameters
 +
 +INTRODUCTION
 +============
 +
 +Consider the situation where a system’s power consumption must be
 +reduced at runtime, due to power budget, thermal constraint, or noise
 +level, and where active cooling is not preferred. Software managed
 +passive power reduction must be performed to prevent the hardware
 +actions that are designed for catastrophic scenarios.
 +
 +Currently, P-states, T-states (clock modulation), and CPU offlining
 +are used for CPU throttling.
 +
 +On Intel CPUs, C-states provide effective power reduction, but so far
 +they’re only used opportunistically, based on workload. With the
 +development of intel_powerclamp driver, the method of synchronizing
 +idle injection across all online CPU threads was introduced. The goal
 +is to achieve forced and controllable C-state residency.
 +
 +Test/Analysis has been made in the areas of power, performance,
 +scalability, and user experience. In many cases, clear advantage is
 +shown over taking the CPU offline or modulating the CPU clock.
 +
 +
 +THEORY OF OPERATION
 +===================
 +
 +Idle Injection
 +--------------
 +
 +On modern Intel processors (Nehalem or later), package level C-state
 +residency is available in MSRs, thus also available to the kernel.
 +
 +These MSRs are::
 +
 +      #define MSR_PKG_C2_RESIDENCY      0x60D
 +      #define MSR_PKG_C3_RESIDENCY      0x3F8
 +      #define MSR_PKG_C6_RESIDENCY      0x3F9
 +      #define MSR_PKG_C7_RESIDENCY      0x3FA
 +
 +If the kernel can also inject idle time to the system, then a
 +closed-loop control system can be established that manages package
 +level C-state. The intel_powerclamp driver is conceived as such a
 +control system, where the target set point is a user-selected idle
 +ratio (based on power reduction), and the error is the difference
 +between the actual package level C-state residency ratio and the target idle
 +ratio.
 +
 +Injection is controlled by high priority kernel threads, spawned for
 +each online CPU.
 +
 +These kernel threads, with SCHED_FIFO class, are created to perform
 +clamping actions of controlled duty ratio and duration. Each per-CPU
 +thread synchronizes its idle time and duration, based on the rounding
 +of jiffies, so accumulated errors can be prevented to avoid a jittery
 +effect. Threads are also bound to the CPU such that they cannot be
 +migrated, unless the CPU is taken offline. In this case, threads
 +belong to the offlined CPUs will be terminated immediately.
 +
 +Running as SCHED_FIFO and relatively high priority, also allows such
++scheme to work for both preemptible and non-preemptible kernels.
 +Alignment of idle time around jiffies ensures scalability for HZ
 +values. This effect can be better visualized using a Perf timechart.
 +The following diagram shows the behavior of kernel thread
 +kidle_inject/cpu. During idle injection, it runs monitor/mwait idle
 +for a given "duration", then relinquishes the CPU to other tasks,
 +until the next time interval.
 +
 +The NOHZ schedule tick is disabled during idle time, but interrupts
 +are not masked. Tests show that the extra wakeups from scheduler tick
 +have a dramatic impact on the effectiveness of the powerclamp driver
 +on large scale systems (Westmere system with 80 processors).
 +
 +::
 +
 +  CPU0
 +                  ____________          ____________
 +  kidle_inject/0   |   sleep    |  mwait |  sleep     |
 +        _________|            |________|            |_______
 +                               duration
 +  CPU1
 +                  ____________          ____________
 +  kidle_inject/1   |   sleep    |  mwait |  sleep     |
 +        _________|            |________|            |_______
 +                              ^
 +                              |
 +                              |
 +                              roundup(jiffies, interval)
 +
 +Only one CPU is allowed to collect statistics and update global
 +control parameters. This CPU is referred to as the controlling CPU in
 +this document. The controlling CPU is elected at runtime, with a
 +policy that favors BSP, taking into account the possibility of a CPU
 +hot-plug.
 +
 +In terms of dynamics of the idle control system, package level idle
 +time is considered largely as a non-causal system where its behavior
 +cannot be based on the past or current input. Therefore, the
 +intel_powerclamp driver attempts to enforce the desired idle time
 +instantly as given input (target idle ratio). After injection,
 +powerclamp monitors the actual idle for a given time window and adjust
 +the next injection accordingly to avoid over/under correction.
 +
 +When used in a causal control system, such as a temperature control,
 +it is up to the user of this driver to implement algorithms where
 +past samples and outputs are included in the feedback. For example, a
 +PID-based thermal controller can use the powerclamp driver to
 +maintain a desired target temperature, based on integral and
 +derivative gains of the past samples.
 +
 +
 +
 +Calibration
 +-----------
 +During scalability testing, it is observed that synchronized actions
 +among CPUs become challenging as the number of cores grows. This is
 +also true for the ability of a system to enter package level C-states.
 +
 +To make sure the intel_powerclamp driver scales well, online
 +calibration is implemented. The goals for doing such a calibration
 +are:
 +
 +a) determine the effective range of idle injection ratio
 +b) determine the amount of compensation needed at each target ratio
 +
 +Compensation to each target ratio consists of two parts:
 +
 +      a) steady state error compensation
 +
 +         This is to offset the error occurring when the system can
 +         enter idle without extra wakeups (such as external interrupts).
 +
 +      b) dynamic error compensation
 +
 +         When an excessive amount of wakeups occurs during idle, an
 +         additional idle ratio can be added to quiet interrupts, by
 +         slowing down CPU activities.
 +
 +A debugfs file is provided for the user to examine compensation
 +progress and results, such as on a Westmere system::
 +
 +  [jacob@nex01 ~]$ cat
 +  /sys/kernel/debug/intel_powerclamp/powerclamp_calib
 +  controlling cpu: 0
 +  pct confidence steady dynamic (compensation)
 +  0       0       0       0
 +  1       1       0       0
 +  2       1       1       0
 +  3       3       1       0
 +  4       3       1       0
 +  5       3       1       0
 +  6       3       1       0
 +  7       3       1       0
 +  8       3       1       0
 +  ...
 +  30      3       2       0
 +  31      3       2       0
 +  32      3       1       0
 +  33      3       2       0
 +  34      3       1       0
 +  35      3       2       0
 +  36      3       1       0
 +  37      3       2       0
 +  38      3       1       0
 +  39      3       2       0
 +  40      3       3       0
 +  41      3       1       0
 +  42      3       2       0
 +  43      3       1       0
 +  44      3       1       0
 +  45      3       2       0
 +  46      3       3       0
 +  47      3       0       0
 +  48      3       2       0
 +  49      3       3       0
 +
 +Calibration occurs during runtime. No offline method is available.
 +Steady state compensation is used only when confidence levels of all
 +adjacent ratios have reached satisfactory level. A confidence level
 +is accumulated based on clean data collected at runtime. Data
 +collected during a period without extra interrupts is considered
 +clean.
 +
 +To compensate for excessive amounts of wakeup during idle, additional
 +idle time is injected when such a condition is detected. Currently,
 +we have a simple algorithm to double the injection ratio. A possible
 +enhancement might be to throttle the offending IRQ, such as delaying
 +EOI for level triggered interrupts. But it is a challenge to be
 +non-intrusive to the scheduler or the IRQ core code.
 +
 +
 +CPU Online/Offline
 +------------------
 +Per-CPU kernel threads are started/stopped upon receiving
 +notifications of CPU hotplug activities. The intel_powerclamp driver
 +keeps track of clamping kernel threads, even after they are migrated
 +to other CPUs, after a CPU offline event.
 +
 +
 +Performance Analysis
 +====================
 +This section describes the general performance data collected on
 +multiple systems, including Westmere (80P) and Ivy Bridge (4P, 8P).
 +
 +Effectiveness and Limitations
 +-----------------------------
 +The maximum range that idle injection is allowed is capped at 50
 +percent. As mentioned earlier, since interrupts are allowed during
 +forced idle time, excessive interrupts could result in less
 +effectiveness. The extreme case would be doing a ping -f to generated
 +flooded network interrupts without much CPU acknowledgement. In this
 +case, little can be done from the idle injection threads. In most
 +normal cases, such as scp a large file, applications can be throttled
 +by the powerclamp driver, since slowing down the CPU also slows down
 +network protocol processing, which in turn reduces interrupts.
 +
 +When control parameters change at runtime by the controlling CPU, it
 +may take an additional period for the rest of the CPUs to catch up
 +with the changes. During this time, idle injection is out of sync,
 +thus not able to enter package C- states at the expected ratio. But
 +this effect is minor, in that in most cases change to the target
 +ratio is updated much less frequently than the idle injection
 +frequency.
 +
 +Scalability
 +-----------
 +Tests also show a minor, but measurable, difference between the 4P/8P
 +Ivy Bridge system and the 80P Westmere server under 50% idle ratio.
 +More compensation is needed on Westmere for the same amount of
 +target idle ratio. The compensation also increases as the idle ratio
 +gets larger. The above reason constitutes the need for the
 +calibration code.
 +
 +On the IVB 8P system, compared to an offline CPU, powerclamp can
 +achieve up to 40% better performance per watt. (measured by a spin
 +counter summed over per CPU counting threads spawned for all running
 +CPUs).
 +
 +Usage and Interfaces
 +====================
 +The powerclamp driver is registered to the generic thermal layer as a
 +cooling device. Currently, it’s not bound to any thermal zones::
 +
 +  jacob@chromoly:/sys/class/thermal/cooling_device14$ grep . *
 +  cur_state:0
 +  max_state:50
 +  type:intel_powerclamp
 +
 +cur_state allows user to set the desired idle percentage. Writing 0 to
 +cur_state will stop idle injection. Writing a value between 1 and
 +max_state will start the idle injection. Reading cur_state returns the
 +actual and current idle percentage. This may not be the same value
 +set by the user in that current idle percentage depends on workload
 +and includes natural idle. When idle injection is disabled, reading
 +cur_state returns value -1 instead of 0 which is to avoid confusing
 +100% busy state with the disabled state.
 +
 +Example usage:
 +
 +- To inject 25% idle time::
 +
 +      $ sudo sh -c "echo 25 > /sys/class/thermal/cooling_device80/cur_state
 +
 +If the system is not busy and has more than 25% idle time already,
 +then the powerclamp driver will not start idle injection. Using Top
 +will not show idle injection kernel threads.
 +
 +If the system is busy (spin test below) and has less than 25% natural
 +idle time, powerclamp kernel threads will do idle injection. Forced
 +idle time is accounted as normal idle in that common code path is
 +taken as the idle task.
 +
 +In this example, 24.1% idle is shown. This helps the system admin or
 +user determine the cause of slowdown, when a powerclamp driver is in action::
 +
 +
 +  Tasks: 197 total,   1 running, 196 sleeping,   0 stopped,   0 zombie
 +  Cpu(s): 71.2%us,  4.7%sy,  0.0%ni, 24.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
 +  Mem:   3943228k total,  1689632k used,  2253596k free,    74960k buffers
 +  Swap:  4087804k total,        0k used,  4087804k free,   945336k cached
 +
 +    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 +   3352 jacob     20   0  262m  644  428 S  286  0.0   0:17.16 spin
 +   3341 root     -51   0     0    0    0 D   25  0.0   0:01.62 kidle_inject/0
 +   3344 root     -51   0     0    0    0 D   25  0.0   0:01.60 kidle_inject/3
 +   3342 root     -51   0     0    0    0 D   25  0.0   0:01.61 kidle_inject/1
 +   3343 root     -51   0     0    0    0 D   25  0.0   0:01.60 kidle_inject/2
 +   2935 jacob     20   0  696m 125m  35m S    5  3.3   0:31.11 firefox
 +   1546 root      20   0  158m  20m 6640 S    3  0.5   0:26.97 Xorg
 +   2100 jacob     20   0 1223m  88m  30m S    3  2.3   0:23.68 compiz
 +
 +Tests have shown that by using the powerclamp driver as a cooling
 +device, a PID based userspace thermal controller can manage to
 +control CPU temperature effectively, when no other thermal influence
 +is added. For example, a UltraBook user can compile the kernel under
 +certain temperature (below most active trip points).
 +
 +Module Parameters
 +=================
 +
 +``cpumask`` (RW)
 +      A bit mask of CPUs to inject idle. The format of the bitmask is same as
 +      used in other subsystems like in /proc/irq/\*/smp_affinity. The mask is
 +      comma separated 32 bit groups. Each CPU is one bit. For example for a 256
 +      CPU system the full mask is:
 +      ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
 +
 +      The rightmost mask is for CPU 0-32.
 +
 +``max_idle`` (RW)
 +      Maximum injected idle time to the total CPU time ratio in percent range
 +      from 1 to 100. Even if the cooling device max_state is always 100 (100%),
 +      this parameter allows to add a max idle percent limit. The default is 50,
 +      to match the current implementation of powerclamp driver. Also doesn't
 +      allow value more than 75, if the cpumask includes every CPU present in
 +      the system.
Simple merge
Simple merge
@@@ -1,8 -1,6 +1,8 @@@
- =========================
- Linux Hardware Monitoring
- =========================
 +.. SPDX-License-Identifier: GPL-2.0
 +
+ ===================
+ Hardware Monitoring
+ ===================
  
  .. toctree::
     :maxdepth: 1
index a9d3e12,0000000..da8e53c
mode 100644,000000..100644
--- /dev/null
@@@ -1,229 -1,0 +1,229 @@@
- For the list of support mlx5 events, check `/sys/kernel/debug/tracing/events/mlx5/`.
 +.. SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
 +.. include:: <isonum.txt>
 +
 +===========
 +Tracepoints
 +===========
 +
 +:Copyright: |copy| 2023, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
 +
 +mlx5 driver provides internal tracepoints for tracking and debugging using
 +kernel tracepoints interfaces (refer to Documentation/trace/ftrace.rst).
 +
-     $ echo mlx5:mlx5e_configure_flower >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++For the list of support mlx5 events, check /sys/kernel/tracing/events/mlx5/.
 +
 +tc and eswitch offloads tracepoints:
 +
 +- mlx5e_configure_flower: trace flower filter actions and cookies offloaded to mlx5::
 +
-     $ echo mlx5:mlx5e_delete_flower >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5e_configure_flower >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    tc-6535  [019] ...1  2672.404466: mlx5e_configure_flower: cookie=0000000067874a55 actions= REDIRECT
 +
 +- mlx5e_delete_flower: trace flower filter actions and cookies deleted from mlx5::
 +
-     $ echo mlx5:mlx5e_stats_flower >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5e_delete_flower >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    tc-6569  [010] .N.1  2686.379075: mlx5e_delete_flower: cookie=0000000067874a55 actions= NULL
 +
 +- mlx5e_stats_flower: trace flower stats request::
 +
-     $ echo mlx5:mlx5e_tc_update_neigh_used_value >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5e_stats_flower >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    tc-6546  [010] ...1  2679.704889: mlx5e_stats_flower: cookie=0000000060eb3d6a bytes=0 packets=0 lastused=4295560217
 +
 +- mlx5e_tc_update_neigh_used_value: trace tunnel rule neigh update value offloaded to mlx5::
 +
-     $ echo mlx5:mlx5e_rep_neigh_update >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5e_tc_update_neigh_used_value >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    kworker/u48:4-8806  [009] ...1 55117.882428: mlx5e_tc_update_neigh_used_value: netdev: ens1f0 IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_used=1
 +
 +- mlx5e_rep_neigh_update: trace neigh update tasks scheduled due to neigh state change events::
 +
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5e_rep_neigh_update >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    kworker/u48:7-2221  [009] ...1  1475.387435: mlx5e_rep_neigh_update: netdev: ens1f0 MAC: 24:8a:07:9a:17:9a IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_connected=1
 +
 +Bridge offloads tracepoints:
 +
 +- mlx5_esw_bridge_fdb_entry_init: trace bridge FDB entry offloaded to mlx5::
 +
 +    $ echo mlx5:mlx5_esw_bridge_fdb_entry_init >> set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    kworker/u20:9-2217    [003] ...1   318.582243: mlx5_esw_bridge_fdb_entry_init: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=0 flags=0 used=0
 +
 +- mlx5_esw_bridge_fdb_entry_cleanup: trace bridge FDB entry deleted from mlx5::
 +
 +    $ echo mlx5:mlx5_esw_bridge_fdb_entry_cleanup >> set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    ip-2581    [005] ...1   318.629871: mlx5_esw_bridge_fdb_entry_cleanup: net_device=enp8s0f0_1 addr=e4:fd:05:08:00:03 vid=0 flags=0 used=16
 +
 +- mlx5_esw_bridge_fdb_entry_refresh: trace bridge FDB entry offload refreshed in
 +  mlx5::
 +
 +    $ echo mlx5:mlx5_esw_bridge_fdb_entry_refresh >> set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    kworker/u20:8-3849    [003] ...1       466716: mlx5_esw_bridge_fdb_entry_refresh: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=3 flags=0 used=0
 +
 +- mlx5_esw_bridge_vlan_create: trace bridge VLAN object add on mlx5
 +  representor::
 +
 +    $ echo mlx5:mlx5_esw_bridge_vlan_create >> set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    ip-2560    [007] ...1   318.460258: mlx5_esw_bridge_vlan_create: vid=1 flags=6
 +
 +- mlx5_esw_bridge_vlan_cleanup: trace bridge VLAN object delete from mlx5
 +  representor::
 +
 +    $ echo mlx5:mlx5_esw_bridge_vlan_cleanup >> set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    bridge-2582    [007] ...1   318.653496: mlx5_esw_bridge_vlan_cleanup: vid=2 flags=8
 +
 +- mlx5_esw_bridge_vport_init: trace mlx5 vport assigned with bridge upper
 +  device::
 +
 +    $ echo mlx5:mlx5_esw_bridge_vport_init >> set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    ip-2560    [007] ...1   318.458915: mlx5_esw_bridge_vport_init: vport_num=1
 +
 +- mlx5_esw_bridge_vport_cleanup: trace mlx5 vport removed from bridge upper
 +  device::
 +
 +    $ echo mlx5:mlx5_esw_bridge_vport_cleanup >> set_event
-     $ echo mlx5:mlx5_esw_vport_qos_create >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    ip-5387    [000] ...1       573713: mlx5_esw_bridge_vport_cleanup: vport_num=1
 +
 +Eswitch QoS tracepoints:
 +
 +- mlx5_esw_vport_qos_create: trace creation of transmit scheduler arbiter for vport::
 +
-     $ echo mlx5:mlx5_esw_vport_qos_config >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_esw_vport_qos_create >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    <...>-23496   [018] .... 73136.838831: mlx5_esw_vport_qos_create: (0000:82:00.0) vport=2 tsar_ix=4 bw_share=0, max_rate=0 group=000000007b576bb3
 +
 +- mlx5_esw_vport_qos_config: trace configuration of transmit scheduler arbiter for vport::
 +
-     $ echo mlx5:mlx5_esw_vport_qos_destroy >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_esw_vport_qos_config >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    <...>-26548   [023] .... 75754.223823: mlx5_esw_vport_qos_config: (0000:82:00.0) vport=1 tsar_ix=3 bw_share=34, max_rate=10000 group=000000007b576bb3
 +
 +- mlx5_esw_vport_qos_destroy: trace deletion of transmit scheduler arbiter for vport::
 +
-     $ echo mlx5:mlx5_esw_group_qos_create >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_esw_vport_qos_destroy >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    <...>-27418   [004] .... 76546.680901: mlx5_esw_vport_qos_destroy: (0000:82:00.0) vport=1 tsar_ix=3
 +
 +- mlx5_esw_group_qos_create: trace creation of transmit scheduler arbiter for rate group::
 +
-     $ echo mlx5:mlx5_esw_group_qos_config >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_esw_group_qos_create >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    <...>-26578   [008] .... 75776.022112: mlx5_esw_group_qos_create: (0000:82:00.0) group=000000008dac63ea tsar_ix=5
 +
 +- mlx5_esw_group_qos_config: trace configuration of transmit scheduler arbiter for rate group::
 +
-     $ echo mlx5:mlx5_esw_group_qos_destroy >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_esw_group_qos_config >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    <...>-27303   [020] .... 76461.455356: mlx5_esw_group_qos_config: (0000:82:00.0) group=000000008dac63ea tsar_ix=5 bw_share=100 max_rate=20000
 +
 +- mlx5_esw_group_qos_destroy: trace deletion of transmit scheduler arbiter for group::
 +
-     $ echo mlx5:mlx5_sf_add >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_esw_group_qos_destroy >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    <...>-27418   [006] .... 76547.187258: mlx5_esw_group_qos_destroy: (0000:82:00.0) group=000000007b576bb3 tsar_ix=1
 +
 +SF tracepoints:
 +
 +- mlx5_sf_add: trace addition of the SF port::
 +
-     $ echo mlx5:mlx5_sf_free >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_add >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    devlink-9363    [031] ..... 24610.188722: mlx5_sf_add: (0000:06:00.0) port_index=32768 controller=0 hw_id=0x8000 sfnum=88
 +
 +- mlx5_sf_free: trace freeing of the SF port::
 +
-     $ echo mlx5:mlx5_sf_activate >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_free >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    devlink-9830    [038] ..... 26300.404749: mlx5_sf_free: (0000:06:00.0) port_index=32768 controller=0 hw_id=0x8000
 +
 +- mlx5_sf_activate: trace activation of the SF port::
 +
-     $ echo mlx5:mlx5_sf_deactivate >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_activate >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    devlink-29841   [008] .....  3669.635095: mlx5_sf_activate: (0000:08:00.0) port_index=32768 controller=0 hw_id=0x8000
 +
 +- mlx5_sf_deactivate: trace deactivation of the SF port::
 +
-     $ echo mlx5:mlx5_sf_hwc_alloc >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_deactivate >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    devlink-29994   [008] .....  4015.969467: mlx5_sf_deactivate: (0000:08:00.0) port_index=32768 controller=0 hw_id=0x8000
 +
 +- mlx5_sf_hwc_alloc: trace allocating of the hardware SF context::
 +
-     $ echo mlx5:mlx5_sf_hwc_free >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_hwc_alloc >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    devlink-9775    [031] ..... 26296.385259: mlx5_sf_hwc_alloc: (0000:06:00.0) controller=0 hw_id=0x8000 sfnum=88
 +
 +- mlx5_sf_hwc_free: trace freeing of the hardware SF context::
 +
-     $ echo mlx5:mlx5_sf_hwc_deferred_free >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_hwc_free >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    kworker/u128:3-9093    [046] ..... 24625.365771: mlx5_sf_hwc_free: (0000:06:00.0) hw_id=0x8000
 +
 +- mlx5_sf_hwc_deferred_free: trace deferred freeing of the hardware SF context::
 +
-     $ echo mlx5:mlx5_sf_update_state >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_hwc_deferred_free >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    devlink-9519    [046] ..... 24624.400271: mlx5_sf_hwc_deferred_free: (0000:06:00.0) hw_id=0x8000
 +
 +- mlx5_sf_update_state: trace state updates for SF contexts::
 +
-     $ echo mlx5:mlx5_sf_vhca_event >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_update_state >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    kworker/u20:3-29490   [009] .....  4141.453530: mlx5_sf_update_state: (0000:08:00.0) port_index=32768 controller=0 hw_id=0x8000 state=2
 +
 +- mlx5_sf_vhca_event: trace SF vhca event and state::
 +
-     $ echo mlx5:mlx5_sf_dev_add>> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_vhca_event >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    kworker/u128:3-9093    [046] ..... 24625.365525: mlx5_sf_vhca_event: (0000:06:00.0) hw_id=0x8000 sfnum=88 vhca_state=1
 +
 +- mlx5_sf_dev_add: trace SF device add event::
 +
-     $ echo mlx5:mlx5_sf_dev_del >> /sys/kernel/debug/tracing/set_event
-     $ cat /sys/kernel/debug/tracing/trace
++    $ echo mlx5:mlx5_sf_dev_add>> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    kworker/u128:3-9093    [000] ..... 24616.524495: mlx5_sf_dev_add: (0000:06:00.0) sfdev=00000000fc5d96fd aux_id=4 hw_id=0x8000 sfnum=88
 +
 +- mlx5_sf_dev_del: trace SF device delete event::
 +
++    $ echo mlx5:mlx5_sf_dev_del >> /sys/kernel/tracing/set_event
++    $ cat /sys/kernel/tracing/trace
 +    ...
 +    kworker/u128:3-9093    [044] ..... 24624.400749: mlx5_sf_dev_del: (0000:06:00.0) sfdev=00000000fc5d96fd aux_id=4 hw_id=0x8000 sfnum=88
Simple merge
Simple merge
Simple merge