intel_pstate CPU Performance Scaling Driver

Copyright (c) 2017 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>

General Information

intel_pstate is a part of theCPU performance scaling subsystem in the Linux kernel(CPUFreq). It is a scaling driver for the Sandy Bridge and latergenerations of Intel processors. Note, however, that some of those processorsmay not be supported. [To understandintel_pstate it is necessary to knowhowCPUFreq works in general, so this is the time to readCPU Performance Scaling ifyou have not done that yet.]

For the processors supported byintel_pstate, the P-state concept is broaderthan just an operating frequency or an operating performance point (see theLinuxCon Europe 2015 presentation by Kristen Accardi for moreinformation about that). For this reason, the representation of P-states usedbyintel_pstate internally follows the hardware specification (for detailsrefer toIntel® 64 and IA-32 Architectures Software Developer’s ManualVolume 3: System Programming Guide). However, theCPUFreq coreuses frequencies for identifying operating performance points of CPUs andfrequencies are involved in the user space interface exposed by it, sointel_pstate maps its internal representation of P-states to frequencies too(fortunately, that mapping is unambiguous). At the same time, it would not bepractical forintel_pstate to supply theCPUFreq core with a table ofavailable frequencies due to the possible size of it, so the driver does not dothat. Some functionality of the core is limited by that.

Since the hardware P-state selection interface used byintel_pstate isavailable at the logical CPU level, the driver always works with individualCPUs. Consequently, ifintel_pstate is in use, everyCPUFreq policyobject corresponds to one logical CPU andCPUFreq policies are effectivelyequivalent to CPUs. In particular, this means that they become “inactive” everytime the corresponding CPU is taken offline and need to be re-initialized whenit goes back online.

intel_pstate is not modular, so it cannot be unloaded, which means that theonly way to pass early-configuration-time parameters to it is via the kernelcommand line. However, its configuration can be adjusted viasysfs to agreat extent. In some configurations it even is possible to unregister it viasysfs which allows anotherCPUFreq scaling driver to be loaded andregistered (seebelow).

Operation Modes

intel_pstate can operate in three different modes: in the active mode withor without hardware-managed P-states support and in the passive mode. Which ofthem will be in effect depends on what kernel command line options are used andon the capabilities of the processor.

Active Mode

This is the default operation mode ofintel_pstate. If it works in thismode, thescaling_driver policy attribute insysfs for allCPUFreqpolicies contains the string “intel_pstate”.

In this mode the driver bypasses the scaling governors layer ofCPUFreq andprovides its own scaling algorithms for P-state selection. Those algorithmscan be applied toCPUFreq policies in the same way as generic scalinggovernors (that is, through thescaling_governor policy attribute insysfs). [Note that different P-state selection algorithms may be chosen fordifferent policies, but that is not recommended.]

They are not generic scaling governors, but their names are the same as thenames of some of those governors. Moreover, confusingly enough, they generallydo not work in the same way as the generic governors they share the names with.For example, thepowersave P-state selection algorithm provided byintel_pstate is not a counterpart of the genericpowersave governor(roughly, it corresponds to theschedutil andondemand governors).

There are two P-state selection algorithms provided byintel_pstate in theactive mode:powersave andperformance. The way they both operatedepends on whether or not the hardware-managed P-states (HWP) feature has beenenabled in the processor and possibly on the processor model.

Which of the P-state selection algorithms is used by default depends on theCONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE kernel configuration option.Namely, if that option is set, theperformance algorithm will be used bydefault, and the other one will be used by default if it is not set.

Active Mode With HWP

If the processor supports the HWP feature, it will be enabled during theprocessor initialization and cannot be disabled after that. It is possibleto avoid enabling it by passing theintel_pstate=no_hwp argument to thekernel in the command line.

If the HWP feature has been enabled,intel_pstate relies on the processor toselect P-states by itself, but still it can give hints to the processor’sinternal P-state selection logic. What those hints are depends on which P-stateselection algorithm has been applied to the given policy (or to the CPU itcorresponds to).

Even though the P-state selection is carried out by the processor automatically,intel_pstate registers utilization update callbacks with the CPU schedulerin this mode. However, they are not used for running a P-state selectionalgorithm, but for periodic updates of the current CPU frequency information tobe made available from thescaling_cur_freq policy attribute insysfs.

HWP +performance

In this configurationintel_pstate will write 0 to the processor’sEnergy-Performance Preference (EPP) knob (if supported) or itsEnergy-Performance Bias (EPB) knob (otherwise), which means that the processor’sinternal P-state selection logic is expected to focus entirely on performance.

This will override the EPP/EPB setting coming from thesysfs interface(seeEnergy vs Performance Hints below).

Also, in this configuration the range of P-states available to the processor’sinternal P-state selection logic is always restricted to the upper boundary(that is, the maximum P-state that the driver is allowed to use).

HWP +powersave

In this configurationintel_pstate will set the processor’sEnergy-Performance Preference (EPP) knob (if supported) or itsEnergy-Performance Bias (EPB) knob (otherwise) to whatever value it waspreviously set to viasysfs (or whatever default value it wasset to by the platform firmware). This usually causes the processor’sinternal P-state selection logic to be less performance-focused.

Active Mode Without HWP

This is the default operation mode for processors that do not support the HWPfeature. It also is used by default with theintel_pstate=no_hwp argumentin the kernel command line. However, in this modeintel_pstate may refuseto work with the given processor if it does not recognize it. [Note thatintel_pstate will never refuse to work with any processor with the HWPfeature enabled.]

In this modeintel_pstate registers utilization update callbacks with theCPU scheduler in order to run a P-state selection algorithm, eitherpowersave orperformance, depending on thescaling_governor policysetting insysfs. The current CPU frequency information to be madeavailable from thescaling_cur_freq policy attribute insysfs isperiodically updated by those utilization update callbacks too.

performance

Without HWP, this P-state selection algorithm is always the same regardless ofthe processor model and platform configuration.

It selects the maximum P-state it is allowed to use, subject to limits set viasysfs, every time the driver configuration for the given CPU is updated(e.g. viasysfs).

This is the default P-state selection algorithm if theCONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE kernel configuration optionis set.

powersave

Without HWP, this P-state selection algorithm is similar to the algorithmimplemented by the genericschedutil scaling governor except that theutilization metric used by it is based on numbers coming from feedbackregisters of the CPU. It generally selects P-states proportional to thecurrent CPU utilization.

This algorithm is run by the driver’s utilization update callback for thegiven CPU when it is invoked by the CPU scheduler, but not more often thanevery 10 ms. Like in theperformance case, the hardware configurationis not touched if the new P-state turns out to be the same as the currentone.

This is the default P-state selection algorithm if theCONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE kernel configuration optionis not set.

Passive Mode

This mode is used if theintel_pstate=passive argument is passed to thekernel in the command line (it implies theintel_pstate=no_hwp setting too).Like in the active mode without HWP support, in this modeintel_pstate mayrefuse to work with the given processor if it does not recognize it.

If the driver works in this mode, thescaling_driver policy attribute insysfs for allCPUFreq policies contains the string “intel_cpufreq”.Then, the driver behaves like a regularCPUFreq scaling driver. That is,it is invoked by generic scaling governors when necessary to talk to thehardware in order to change the P-state of a CPU (in particular, theschedutil governor can invoke it directly from scheduler context).

While in this mode,intel_pstate can be used with all of the (generic)scaling governors listed by thescaling_available_governors policy attributeinsysfs (and the P-state selection algorithms described above are notused). Then, it is responsible for the configuration of policy objectscorresponding to CPUs and provides theCPUFreq core (and the scalinggovernors attached to the policy objects) with accurate information on themaximum and minimum operating frequencies supported by the hardware (includingthe so-called “turbo” frequency ranges). In other words, in the passive modethe entire range of available P-states is exposed byintel_pstate to theCPUFreq core. However, in this mode the driver does not registerutilization update callbacks with the CPU scheduler and thescaling_cur_freqinformation comes from theCPUFreq core (and is the last frequency selectedby the current scaling governor for the given policy).

Turbo P-states Support

In the majority of cases, the entire range of P-states available tointel_pstate can be divided into two sub-ranges that correspond todifferent types of processor behavior, above and below a boundary thatwill be referred to as the “turbo threshold” in what follows.

The P-states above the turbo threshold are referred to as “turbo P-states” andthe whole sub-range of P-states they belong to is referred to as the “turborange”. These names are related to the Turbo Boost technology allowing amulticore processor to opportunistically increase the P-state of one or morecores if there is enough power to do that and if that is not going to cause thethermal envelope of the processor package to be exceeded.

Specifically, if software sets the P-state of a CPU core within the turbo range(that is, above the turbo threshold), the processor is permitted to take overperformance scaling control for that core and put it into turbo P-states of itschoice going forward. However, that permission is interpreted differently bydifferent processor generations. Namely, the Sandy Bridge generation ofprocessors will never use any P-states above the last one set by software forthe given core, even if it is within the turbo range, whereas all of the laterprocessor generations will take it as a license to use any P-states from theturbo range, even above the one set by software. In other words, on thoseprocessors setting any P-state from the turbo range will enable the processorto put the given core into all turbo P-states up to and including the maximumsupported one as it sees fit.

One important property of turbo P-states is that they are not sustainable. Moreprecisely, there is no guarantee that any CPUs will be able to stay in any ofthose states indefinitely, because the power distribution within the processorpackage may change over time or the thermal envelope it was designed for mightbe exceeded if a turbo P-state was used for too long.

In turn, the P-states below the turbo threshold generally are sustainable. Infact, if one of them is set by software, the processor is not expected to changeit to a lower one unless in a thermal stress or a power limit violationsituation (a higher P-state may still be used if it is set for another CPU inthe same package at the same time, for example).

Some processors allow multiple cores to be in turbo P-states at the same time,but the maximum P-state that can be set for them generally depends on the numberof cores running concurrently. The maximum turbo P-state that can be set for 3cores at the same time usually is lower than the analogous maximum P-state for2 cores, which in turn usually is lower than the maximum turbo P-state that canbe set for 1 core. The one-core maximum turbo P-state is thus the maximumsupported one overall.

The maximum supported turbo P-state, the turbo threshold (the maximum supportednon-turbo P-state) and the minimum supported P-state are specific to theprocessor model and can be determined by reading the processor’s model-specificregisters (MSRs). Moreover, some processors support the Configurable TDP(Thermal Design Power) feature and, when that feature is enabled, the turbothreshold effectively becomes a configurable value that can be set by theplatform firmware.

Unlike_PSS objects in the ACPI tables,intel_pstate always exposesthe entire range of available P-states, including the whole turbo range, to theCPUFreq core and (in the passive mode) to generic scaling governors. Thisgenerally causes turbo P-states to be set more often whenintel_pstate isused relative to ACPI-based CPU performance scaling (seebelowfor more information).

Moreover, sinceintel_pstate always knows what the real turbo threshold is(even if the Configurable TDP feature is enabled in the processor), itsno_turbo attribute insysfs (describedbelow) shouldwork as expected in all cases (that is, if set to disable turbo P-states, italways should preventintel_pstate from using them).

Processor Support

To handle a given processorintel_pstate requires a number of differentpieces of information on it to be known, including:

  • The minimum supported P-state.
  • The maximum supportednon-turbo P-state.
  • Whether or not turbo P-states are supported at all.
  • The maximum supportedone-core turbo P-state (if turbo P-statesare supported).
  • The scaling formula to translate the driver’s internal representationof P-states into frequencies and the other way around.

Generally, ways to obtain that information are specific to the processor modelor family. Although it often is possible to obtain all of it from the processoritself (using model-specific registers), there are cases in which hardwaremanuals need to be consulted to get to it too.

For this reason, there is a list of supported processors inintel_pstate andthe driver initialization will fail if the detected processor is not in thatlist, unless it supports theHWP feature. [The interface toobtain all of the information listed above is the same for all of the processorssupporting the HWP feature, which is why they all are supported byintel_pstate.]

User Space Interface insysfs

Global Attributes

intel_pstate exposes several global attributes (files) insysfs tocontrol its functionality at the system level. They are located in the/sys/devices/system/cpu/intel_pstate/ directory and affect all CPUs.

Some of them are not present if theintel_pstate=per_cpu_perf_limitsargument is passed to the kernel in the command line.

max_perf_pct

Maximum P-state the driver is allowed to set in percent of themaximum supported performance level (the highest supportedturboP-state).

This attribute will not be exposed if theintel_pstate=per_cpu_perf_limits argument is present in the kernelcommand line.

min_perf_pct

Minimum P-state the driver is allowed to set in percent of themaximum supported performance level (the highest supportedturboP-state).

This attribute will not be exposed if theintel_pstate=per_cpu_perf_limits argument is present in the kernelcommand line.

num_pstates

Number of P-states supported by the processor (between 0 and 255inclusive) including both turbo and non-turbo P-states (seeTurbo P-states Support).

The value of this attribute is not affected by theno_turbosetting describedbelow.

This attribute is read-only.

turbo_pct

Ratio of theturbo range size to the size of the entirerange of supported P-states, in percent.

This attribute is read-only.

no_turbo

If set (equal to 1), the driver is not allowed to set any turbo P-states(seeTurbo P-states Support). If unset (equalt to 0, which is thedefault), turbo P-states can be set by the driver.[Note thatintel_pstate does not support the generalboostattribute (supported by some other scaling drivers) which is replacedby this one.]

This attrubute does not affect the maximum supported frequency valuesupplied to theCPUFreq core and exposed via the policy interface,but it affects the maximum possible value of per-policy P-state limits(seeInterpretation of Policy Attributes below for details).

hwp_dynamic_boost

This attribute is only present ifintel_pstate works in theactive mode with the HWP feature enabled inthe processor. If set (equal to 1), it causes the minimum P-state limitto be increased dynamically for a short time whenever a task previouslywaiting on I/O is selected to run on a given logical CPU (the purposeof this mechanism is to improve performance).

This setting has no effect on logical CPUs whose minimum P-state limitis directly set to the highest non-turbo P-state or above it.

status

Operation mode of the driver: “active”, “passive” or “off”.

“active”
The driver is functional and in theactive mode.
“passive”
The driver is functional and in thepassive mode.
“off”
The driver is not functional (it is not registered as a scalingdriver with theCPUFreq core).

This attribute can be written to in order to change the driver’soperation mode or to unregister it. The string written to it must beone of the possible values of it and, if successful, the write willcause the driver to switch over to the operation mode represented bythat string - or to be unregistered in the “off” case. [Actually,switching over from the active mode to the passive mode or the otherway around causes the driver to be unregistered and registered againwith a different set of callbacks, so all of its settings (the globalas well as the per-policy ones) are then reset to their defaultvalues, possibly depending on the target operation mode.]

That only is supported in some configurations, though (for example, iftheHWP feature is enabled in the processor,the operation mode of the driver cannot be changed), and if it is notsupported in the current configuration, writes to this attribute willfail with an appropriate error.

Interpretation of Policy Attributes

The interpretation of someCPUFreq policy attributes described inCPU Performance Scaling is special withintel_pstate as the current scaling driverand it generally depends on the driver’soperation mode.

First of all, the values of thecpuinfo_max_freq,cpuinfo_min_freq andscaling_cur_freq attributes are produced by applying a processor-specificmultiplier to the internal P-state representation used byintel_pstate.Also, the values of thescaling_max_freq andscaling_min_freqattributes are capped by the frequency corresponding to the maximum P-state thatthe driver is allowed to set.

If theno_turboglobal attribute is set, the driver isnot allowed to use turbo P-states, so the maximum value ofscaling_max_freqandscaling_min_freq is limited to the maximum non-turbo P-state frequency.Accordingly, settingno_turbo causesscaling_max_freq andscaling_min_freq to go down to that value if they were above it before.However, the old values ofscaling_max_freq andscaling_min_freq will berestored after unsettingno_turbo, unless these attributes have been writtento afterno_turbo was set.

Ifno_turbo is not set, the maximum possible value ofscaling_max_freqandscaling_min_freq corresponds to the maximum supported turbo P-state,which also is the value ofcpuinfo_max_freq in either case.

Next, the following policy attributes have special meaning ifintel_pstate works in theactive mode:

scaling_available_governors
List of P-state selection algorithms provided byintel_pstate.
scaling_governor
P-state selection algorithm provided byintel_pstate currently inuse with the given policy.
scaling_cur_freq
Frequency of the average P-state of the CPU represented by the givenpolicy for the time interval between the last two invocations of thedriver’s utilization update callback by the CPU scheduler for that CPU.

The meaning of these attributes in thepassive mode is thesame as for other scaling drivers.

Additionally, the value of thescaling_driver attribute forintel_pstatedepends on the operation mode of the driver. Namely, it is either“intel_pstate” (in theactive mode) or “intel_cpufreq” (in thepassive mode).

Coordination of P-State Limits

intel_pstate allows P-state limits to be set in two ways: with the help ofthemax_perf_pct andmin_perf_pctglobal attributes or via thescaling_max_freq andscaling_min_freqCPUFreq policy attributes. The coordination between those limits is basedon the following rules, regardless of the current operation mode of the driver:

  1. All CPUs are affected by the global limits (that is, none of them can berequested to run faster than the global maximum and none of them can berequested to run slower than the global minimum).
  2. Each individual CPU is affected by its own per-policy limits (that is, itcannot be requested to run faster than its own per-policy maximum and itcannot be requested to run slower than its own per-policy minimum).
  3. The global and per-policy limits can be set independently.

If theHWP feature is enabled in the processor, theresulting effective values are written into its registers whenever the limitschange in order to request its internal P-state selection logic to always setP-states within these limits. Otherwise, the limits are taken into account byscaling governors (in thepassive mode) and by the driverevery time before setting a new P-state for a CPU.

Additionally, if theintel_pstate=per_cpu_perf_limits command line argumentis passed to the kernel,max_perf_pct andmin_perf_pct are not exposedat all and the only way to set the limits is by using the policy attributes.

Energy vs Performance Hints

Ifintel_pstate works in theactive mode with the HWP feature enabled in the processor, additional attributes are presentin everyCPUFreq policy directory insysfs. They are intended to allowuser space to helpintel_pstate to adjust the processor’s internal P-stateselection logic by focusing it on performance or on energy-efficiency, orsomewhere between the two extremes:

energy_performance_preference

Current value of the energy vs performance hint for the given policy(or the CPU represented by it).

The hint can be changed by writing to this attribute.

energy_performance_available_preferences

List of strings that can be written to theenergy_performance_preference attribute.

They represent different energy vs performance hints and should beself-explanatory, except thatdefault represents whatever hintvalue was set by the platform firmware.

Strings written to theenergy_performance_preference attribute areinternally translated to integer values written to the processor’sEnergy-Performance Preference (EPP) knob (if supported) or itsEnergy-Performance Bias (EPB) knob.

[Note that tasks may by migrated from one CPU to another by the scheduler’sload-balancing algorithm and if different energy vs performance hints areset for those CPUs, that may lead to undesirable outcomes. To avoid suchissues it is better to set the same energy vs performance hint for all CPUsor to pin every task potentially sensitive to them to a specific CPU.]

intel_pstate vsacpi-cpufreq

On the majority of systems supported byintel_pstate, the ACPI tablesprovided by the platform firmware contain_PSS objects returning informationthat can be used for CPU performance scaling (refer to theACPI specificationfor details on the_PSS objects and the format of the information returnedby them).

The information returned by the ACPI_PSS objects is used by theacpi-cpufreq scaling driver. On systems supported byintel_pstatetheacpi-cpufreq driver uses the same hardware CPU performance scalinginterface, but the set of P-states it can use is limited by the_PSSoutput.

On those systems each_PSS object returns a list of P-states supported bythe corresponding CPU which basically is a subset of the P-states range that canbe used byintel_pstate on the same system, with one exception: the wholeturbo range is represented by one item in it (the topmost one). Byconvention, the frequency returned by_PSS for that item is greater by 1 MHzthan the frequency of the highest non-turbo P-state listed by it, but thecorresponding P-state representation (following the hardware specification)returned for it matches the maximum supported turbo P-state (or is thespecial value 255 meaning essentially “go as high as you can get”).

The list of P-states returned by_PSS is reflected by the table ofavailable frequencies supplied byacpi-cpufreq to theCPUFreq core andscaling governors and the minimum and maximum supported frequencies reported byit come from that list as well. In particular, given the special representationof the turbo range described above, this means that the maximum supportedfrequency reported byacpi-cpufreq is higher by 1 MHz than the frequencyof the highest supported non-turbo P-state listed by_PSS which, of course,affects decisions made by the scaling governors, except forpowersave andperformance.

For example, if a given governor attempts to select a frequency proportional toestimated CPU load and maps the load of 100% to the maximum supported frequency(possibly multiplied by a constant), then it will tend to choose P-states belowthe turbo threshold ifacpi-cpufreq is used as the scaling driver, becausein that case the turbo range corresponds to a small fraction of the frequencyband it can use (1 MHz vs 1 GHz or more). In consequence, it will only go tothe turbo range for the highest loads and the other loads above 50% that mightbenefit from running at turbo frequencies will be given non-turbo P-statesinstead.

One more issue related to that may appear on systems supporting theConfigurable TDP feature allowing the platform firmware to set theturbo threshold. Namely, if that is not coordinated with the lists of P-statesreturned by_PSS properly, there may be more than one item corresponding toa turbo P-state in those lists and there may be a problem with avoiding theturbo range (if desirable or necessary). Usually, to avoid using turboP-states overall,acpi-cpufreq simply avoids using the topmost state listedby_PSS, but that is not sufficient when there are other turbo P-states inthe list returned by it.

Apart from the above,acpi-cpufreq works likeintel_pstate in thepassive mode, except that the number of P-states it can setis limited to the ones listed by the ACPI_PSS objects.

Kernel Command Line Options forintel_pstate

Several kernel command line options can be used to pass early-configuration-timeparameters tointel_pstate in order to enforce specific behavior of it. Allof them have to be prepended with theintel_pstate= prefix.

disable
Do not registerintel_pstate as the scaling driver even if theprocessor is supported by it.
passive

Registerintel_pstate in thepassive mode tostart with.

This option implies theno_hwp one described below.

force

Registerintel_pstate as the scaling driver instead ofacpi-cpufreq even if the latter is preferred on the given system.

This may prevent some platform features (such as thermal controls andpower capping) that rely on the availability of ACPI P-statesinformation from functioning as expected, so it should be used withcaution.

This option does not work with processors that are not supported byintel_pstate and on platforms where thepcc-cpufreq scalingdriver is used instead ofacpi-cpufreq.

no_hwp
Do not enable thehardware-managed P-states (HWP) feature even if it is supported by the processor.
hwp_only
Registerintel_pstate as the scaling driver only if thehardware-managed P-states (HWP) feature issupported by the processor.
support_acpi_ppc

Take ACPI_PPC performance limits into account.

If the preferred power management profile in the FADT (Fixed ACPIDescription Table) is set to “Enterprise Server” or “PerformanceServer”, the ACPI_PPC limits are taken into account by defaultand this option has no effect.

per_cpu_perf_limits
Use per-logical-CPU P-State limits (seeCoordination of P-stateLimits for details).

Diagnostics and Tuning

Trace Events

There are two static trace events that can be used forintel_pstatediagnostics. One of them is thecpu_frequency trace event generally usedbyCPUFreq, and the other one is thepstate_sample trace event specifictointel_pstate. Both of them are triggered byintel_pstate only ifit works in theactive mode.

The following sequence of shell commands can be used to enable them and seetheir output (if the kernel is generally configured to support event tracing):

# cd /sys/kernel/debug/tracing/# echo 1 > events/power/pstate_sample/enable# echo 1 > events/power/cpu_frequency/enable# cat tracegnome-terminal--4510  [001] ..s.  1177.680733: pstate_sample: core_busy=107 scaled=94 from=26 to=26 mperf=1143818 aperf=1230607 tsc=29838618 freq=2474476cat-5235  [002] ..s.  1177.681723: cpu_frequency: state=2900000 cpu_id=2

Ifintel_pstate works in thepassive mode, thecpu_frequency trace event will be triggered either by theschedutilscaling governor (for the policies it is attached to), or by theCPUFreqcore (for the policies with other scaling governors).

ftrace

Theftrace interface can be used for low-level diagnostics ofintel_pstate. For example, to check how often the function to set aP-state is called, theftrace filter can be set to tointel_pstate_set_pstate():

# cd /sys/kernel/debug/tracing/# cat available_filter_functions | grep -i pstateintel_pstate_set_pstateintel_pstate_cpu_init...# echo intel_pstate_set_pstate > set_ftrace_filter# echo function > current_tracer# cat trace | head -15# tracer: function## entries-in-buffer/entries-written: 80/80   #P:4##                              _-----=> irqs-off#                             / _----=> need-resched#                            | / _---=> hardirq/softirq#                            || / _--=> preempt-depth#                            ||| /     delay#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION#              | |       |   ||||       |         |            Xorg-3129  [000] ..s.  2537.644844: intel_pstate_set_pstate <-intel_pstate_timer_func gnome-terminal--4510  [002] ..s.  2537.649844: intel_pstate_set_pstate <-intel_pstate_timer_func     gnome-shell-3409  [001] ..s.  2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func          <idle>-0     [000] ..s.  2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func