Understanding CPU Frequency Scaling and File System Behavior in Linux

When tuning the Linux kernel for performance, there are two key subsystems worth understanding: CPU frequency scaling (the governor) and file system behavior.
Both play a big role in how your system feels — one affects how fast the CPU reacts to workload changes, and the other defines how efficiently Linux handles files, notifications, and inter-process messages.

Let’s unpack both groups of settings.

1. CPU Frequency Scaling (Governor)

What it is:
CPU frequency scaling (also called Dynamic Voltage and Frequency Scaling or DVFS) is the mechanism that adjusts your processor’s clock speed depending on workload and thermal limits. In other words, it’s what decides whether your CPU hums quietly or screams at full turbo.

1.1 Key Idea

The Linux kernel doesn’t just run your CPU flat out — it uses a “governor”, which is like a policy that decides how to scale the frequency.

Common governors include:

• powersave – keeps CPU frequency low to save energy.
• ondemand / schedutil – scales up/down dynamically based on load.
• performance – keeps CPU frequency locked at maximum.

For servers, build machines, and low-latency systems (like gaming rigs or realtime pipelines), the performance governor is the preferred choice. It avoids lag caused by ramp-up delays.

Note: The governor itself isn’t configured via /etc/sysctl.conf. Instead, you manage it using tools like cpupower or by writing directly to /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor.
But some sysctl knobs can affect how the scheduler treats CPU activity.

1.2 The Parameters

kernel.sched_rt_runtime_us = -1

• Default: 950000
• What it means: This value defines how much CPU time (in microseconds) real-time (RT) tasks can use in each scheduler period.
  By default, Linux limits RT tasks to 95% of each second (950000 µs out of 1,000,000 µs) so that normal tasks still get some CPU time.
• Why set to -1:
  Setting it to -1 removes the limit — giving real-time tasks unrestricted CPU access.
  This is critical for workloads that cannot tolerate latency, like:
  • Real-time audio processing
  • Industrial control systems
  • High-frequency trading
  • Low-latency simulation environments

Be careful: If a buggy RT task runs forever, it can starve the rest of the system. Use this setting only when you know your RT processes behave properly.

kernel.sched_rt_period_us = 1000000

• Default: 1000000 (1 second)
• What it means: This defines the total length of the scheduling period for real-time tasks.
• Why keep it:
  You’re telling the kernel, “Use a 1-second cycle, same as default.” Since you already gave unlimited RT runtime, this line ensures the timing logic stays consistent.

Together, these two parameters define how the kernel balances real-time vs. normal tasks.
In this setup, we’ve effectively told Linux:
“Real-time tasks may run all the time if they want to — go wild.”

1.3 Additional Tip

Some performance guides suggest disabling CPU idle states (C-states) or SMT (nosmt) to squeeze out latency. But doing that blindly can waste power and even hurt performance on modern CPUs.
A more balanced approach is to:

1. Use the performance governor.
2. Keep C-states enabled (for deep sleep when idle).
3. Tweak scheduler knobs only where latency truly matters.

You can check your current governor:

cpupower frequency-info | grep "The governor"

And set it globally:

sudo cpupower frequency-set -g performance

2. File System Behavior

Now we switch gears to the kernel’s file system parameters — the hidden dials that control how Linux handles open files, directory watches, and inter-process communication.

fs.file-max = 2097152

• Default: 8192
• What it means: This sets the system-wide limit on how many files can be opened simultaneously.

Why increase:
Modern systems can easily handle millions of file descriptors — think web servers, Docker containers, and build tools that open hundreds of thousands of files.
Raising this limit prevents the dreaded:

Too many open files

error during heavy workloads.

fs.inotify.max_user_watches = 524288

• Default: 8192
• What it means: The number of individual file or directory watches a single user can create via the inotify API.
  This matters for tools like:
  • IDE auto-reloaders (VSCode, IntelliJ, WebStorm)
  • File sync daemons (Nextcloud, Syncthing)
  • Webpack / frontend builds

Why raise: Without this, large projects will crash with errors like:

Error: ENOSPC: System limit for number of file watchers reached

Raising it allows you to watch more files efficiently.

fs.inotify.max_user_instances = 1024

• Default: 128
• What it means: Limits how many separate inotify instances a single user can have.
  Each instance can hold multiple watches. Increasing it helps when you run many independent applications using file monitoring.

POSIX Message Queues

These parameters control Linux’s message queue system — a mechanism that lets processes send and receive structured messages efficiently (used by IPC and some RT systems).

fs.mqueue.msg_max = 1048576

• Default: 10240
• What it means: Maximum number of messages allowed in a single queue.
• Why raise: More messages mean higher throughput for systems using inter-process queues (for example, real-time logging or telemetry).

fs.mqueue.msgsize_max = 1048576

• Default: 8192
• What it means: Maximum size of a single message (in bytes).
• Why raise: Enables large message payloads (for example, structured data packets or serialized logs).

fs.mqueue.queues_max = 1024

• Default: 256
• What it means: Maximum number of message queues per user.
• Why raise: Useful in systems with many independent real-time or concurrent services.

In short: these values turn your Linux message queue subsystem from a minimal desktop-sized setup into an enterprise-grade, multi-service capable environment.

3. Summary

4. Final Thoughts

This section of your configuration doesn’t magically make Linux “faster.”
What it does is remove artificial bottlenecks — limits that made sense on a 200 MB RAM laptop in 2005 but are absurd on a modern 32-core workstation.

You’re telling the kernel:

“Don’t hold back. I know what I’m doing, and I have the hardware to handle it.”