Direct answer

A CPU power plan can affect Minecraft when the processor does not ramp up for a busy tick thread. Measure tick latency first; do not assume a “performance” governor is always faster or that changing it is supported by your host.

Measure and identify the governor

  1. During a repeatable workload, record /spark tps and a short profiler capture; note the player count and TPS/MSPT.
  2. On a Linux host with CPUFreq, inspect cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor and cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors. Check other policy directories if present.
  3. Compare reported frequency under load with scaling_max_freq and check whether the kernel exposes those files at all.

Interpret the result

Kernel drivers and governors differ: on some systems, performance requests the highest permitted frequency, while a modern hardware-managed policy may work differently. A VPS or managed host may hide or override frequency controls. Do not try to set a governor when your provider owns the host or when the interface is absent.

Version and safety notes

CPUFreq files are Linux-host-specific; cloud guests and managed panels may not expose governors. Never change host policy without administrative permission.

Verify safely

On a machine you administer, compare identical player actions before and after a documented host-level power-policy change. Track MSPT percentiles, temperature and energy/thermal limits as well as frequency. Revert the host policy if there is no consistent improvement.

References

Check documentation for the versions and hosting environment you actually run.