Kernel Configuration Updates

Tuning Parameters for Specific Workload Needs

Part I — The Article

The kernel’s default parameters optimise for a generic workload that probably does not resemble yours. A database under write pressure, a high-connection API gateway, and a latency-sensitive trading engine need fundamentally different kernel behaviour. The knobs exist. The question is whether you understand what each one actually changes.

---

What sysctl Really Does

Every /proc/sys/ entry maps to a ctl_table struct in the kernel, which holds a proc_handler function pointer — typically proc_dointvec_minmax for integers with bounds, proc_doulongvec_minmax for unsigned longs. When you write to /proc/sys/vm/dirty_ratio, the VFS layer calls that handler, which validates the input, writes to the corresponding kernel variable, and in some cases fires a side-effect callback. There is no magic. Writing echo 80 > /proc/sys/vm/dirty_ratio is a write(2) syscall into a synthetic file that executes kernel code.

sysctl -w does the same thing with a slightly nicer interface. sysctl -p replays /etc/sysctl.conf at boot. Understanding this matters because some parameters take effect immediately, others only affect newly created objects (sockets, processes), and a few require a specific kernel subsystem to be re-initialised.

---

The Dirty Page Cliff

The VM subsystem tracks dirty pages — pages modified in the page cache but not yet written to disk — through two thresholds.

vm.dirty_background_ratio (default 10%) is when kworker wakes up and starts writing dirty pages asynchronously. Your application keeps running. vm.dirty_ratio (default 20%) is when your application’s write path blocks inside balance_dirty_pages(), waiting for writeback to catch up. This is the cliff. On a machine with 64 GB RAM, the default dirty_ratio is 12.8 GB of unwritten data before any application thread stalls. Write a log-heavy service that suddenly flushes, and you will see 200–400ms write latency spikes with zero CPU visible in top.

---