Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DeelerDev/linux/llms.txt

Use this file to discover all available pages before exploring further.

Kernel parameters are key-value pairs passed to the Linux kernel at boot time. They control a wide range of behaviors: how much memory the kernel uses, which CPUs to bring online, how verbose logging is, and whether security mitigations are active. Understanding these parameters helps you tune performance, diagnose boot problems, and harden production systems.

​
How parameters are passed

Parameters are placed on the kernel command line, which the bootloader delivers to the kernel before control is handed off. On GRUB-based systems, they live in the GRUB_CMDLINE_LINUX or GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub.
1

Edit the GRUB configuration

sudo nano /etc/default/grub
Add or modify:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash loglevel=3"
2

Regenerate the GRUB config

sudo update-grub
3

Reboot

sudo reboot
To add a parameter temporarily for a single boot, press e at the GRUB menu to edit the boot entry, append the parameter to the linux line, then press Ctrl+X to boot.

​
Viewing current parameters

The kernel exposes the active command line through /proc/cmdline: 
cat /proc/cmdline
Example output: 
BOOT_IMAGE=/boot/vmlinuz-6.8.0 root=UUID=abc123 ro quiet splash loglevel=3
Module parameters that were set at boot can also be inspected at runtime: 
# List parameters for a loaded module
cat /sys/module/<module_name>/parameters/<param>

# Example: check current e1000e interrupt throttle rate
cat /sys/module/e1000e/parameters/InterruptThrottleRate
Parameter names treat hyphens and underscores as equivalent. log_buf_len=1M and log-buf-len=1M both work.

​
Memory parameters

Limits the amount of RAM the kernel will use. Useful for testing low-memory behavior or working around buggy firmware that misreports memory.
mem=4G
Values use binary multipliers: K = 1024, M = 1048576, G = 1073741824.
Allocates N HugeTLB pages at boot time. Pre-allocating huge pages at boot is more reliable than runtime allocation because memory fragmentation has not yet occurred.
hugepages=512
Each huge page is 2 MB on x86_64 by default. 512 pages reserves 1 GB for applications that use MAP_HUGETLB (databases, JVMs with -XX:+UseLargePages).
Controls the kernel’s transparent huge page (THP) behavior:
  • always — promote eligible anonymous mappings to 2 MB pages automatically
  • madvise — only use THP for regions explicitly requested with madvise(MADV_HUGEPAGE)
  • never — disable THP entirely
transparent_hugepage=madvise
madvise is a reasonable default for mixed workloads. Latency-sensitive applications (Redis, real-time audio) often benefit from never to avoid compaction stalls.

​
CPU parameters

Limits the number of CPUs the kernel brings online at boot. Setting maxcpus=1 produces a single-CPU kernel even on an SMP system, which is useful for reproducing race-condition bugs.
maxcpus=4
CPUs not brought online at boot can be enabled later:
echo 1 > /sys/devices/system/cpu/cpu4/online
Removes the listed CPUs from the general scheduler’s domain. Isolated CPUs will not run ordinary tasks unless explicitly assigned with taskset or cgroup cpuset. Useful for real-time workloads and latency-sensitive applications.
isolcpus=2,3,6-11
isolcpus is deprecated in favor of the cpuset cgroup. On modern kernels, prefer creating a dedicated cpuset and assigning tasks to it.
In kernels built with CONFIG_NO_HZ_FULL=y, stops the scheduler tick on the listed CPUs when only one task is running. This eliminates timer interrupt overhead for single-threaded compute tasks.
nohz_full=1-7
The boot CPU (CPU 0) is always excluded from nohz_full to maintain timekeeping. CPUs listed here also have their RCU callbacks offloaded automatically.

​
Debug and logging parameters

Sets the default console log level. Messages with a priority lower than this number (i.e., less severe) are suppressed on the console. Levels range from 0 (emergency) to 7 (debug):
LevelNameMeaning
0KERN_EMERGSystem is unusable
1KERN_ALERTAction must be taken immediately
2KERN_CRITCritical conditions
3KERN_ERRError conditions
4KERN_WARNINGWarning conditions
5KERN_NOTICENormal but significant
6KERN_INFOInformational
7KERN_DEBUGDebug-level messages
loglevel=7
This can also be changed at runtime: dmesg -n 7 or echo 7 > /proc/sys/kernel/printk.
Enables kernel debugging, which sets the console log level to the maximum (7) so all messages appear. Equivalent to loglevel=7 but also enables additional debug-level behavior in some subsystems.
debug
Controls the kernel’s behavior after a panic:
  • panic=0 — hang forever (default; useful for attaching a debugger)
  • panic=N (N > 0) — reboot automatically after N seconds
  • panic=-1 — reboot immediately without delay
panic=30
Production servers typically use panic=1 combined with a watchdog so the system recovers automatically.
Makes the kernel call panic() whenever an oops occurs, instead of the default behavior of killing only the offending process. Useful on production systems where a partial failure is worse than a clean reboot.
oops=panic
Combine with panic=30 to trigger a reboot after capturing a kdump.

​
Security parameters

Controls Page Table Isolation (PTI), the Meltdown mitigation that separates user-space and kernel-space page tables:
  • pti=on — always enable (performance cost on pre-Meltdown CPUs)
  • pti=off — always disable (not recommended on vulnerable hardware)
  • pti=auto — enable only on CPUs known to be vulnerable (default)
pti=auto
Disables Supervisor Mode Access Prevention (nosmap) or Supervisor Mode Execution Prevention (nosmep) on PowerPC. On x86, the equivalent options are controlled at compile time via CONFIG_X86_SMAP and CONFIG_X86_SMEP. Disabling these mitigations reduces security.
Disabling SMAP or SMEP removes kernel protections against certain privilege-escalation techniques. Only disable them for debugging purposes on isolated systems.
On x86-64, controls whether the NX (No-Execute) page attribute is used to prevent code execution in data pages:
  • noexec=on — enforce NX (default)
  • noexec=off — disable NX enforcement
noexec=on

​
I/O and filesystem parameters

Tells the kernel which filesystem type to use for the root filesystem. Normally the kernel detects this automatically, but setting it explicitly can speed up boot by skipping filesystem probing.
rootfstype=ext4
Controls whether the root filesystem is mounted read-only or read-write at boot:
  • ro — mount root read-only (default on most distributions; fsck runs before remounting read-write)
  • rw — mount root read-write immediately, skipping the read-only phase
ro
Selects the I/O scheduler for block devices. On modern kernels with blk-mq, this affects multi-queue schedulers:
  • none — no scheduling, pass-through to hardware queue
  • mq-deadline — deadline scheduling for HDDs
  • kyber — low-latency scheduler for fast NVMe
elevator=mq-deadline
You can also change the scheduler at runtime per device:
echo mq-deadline > /sys/block/sda/queue/scheduler

​
Runtime tuning with sysctl

Many kernel behaviors that cannot be set via command-line parameters can be tuned at runtime through sysctl, which reads and writes files under /proc/sys/: 
# View all current sysctl values
sysctl -a

# Read a specific value
sysctl kernel.panic

# Set a value for the current session
sysctl -w kernel.panic=30

# Set a value permanently (persists across reboots)
echo "kernel.panic = 30" >> /etc/sysctl.d/99-local.conf
sysctl --system
Key sysctl namespaces:
NamespacePurpose
kernel.*Core kernel behavior (panic, printk, hostname)
vm.*Virtual memory (swappiness, dirty ratio, overcommit)
net.*Networking stack (TCP buffers, connection tracking)
fs.*Filesystem limits (file handles, inotify watches)
Use sysctl -p /etc/sysctl.d/99-custom.conf to apply a specific file without rebooting. This is useful for testing sysctl changes before making them permanent.

Build docs developers (and LLMs) love

Get started for freeTalk to us