CPU & Scheduling

Most important commands to remember

• top — watch CPU use and processes live.
• ps — inspect a process’s scheduling settings.
• nice -n 10 COMMAND — start a command with lower scheduling priority by increasing its inherited niceness by 10.

Commands and flags

These commands appear in the short example below.

Command or key	Meaning
top -d 1	Refresh the live display every second; -d sets the interval.
q inside top	Quit the display and return to the shell.
ps -o pid,ni,comm	-o selects the columns: process ID, niceness, and program name.
nice -n 10 COMMAND	-n 10 adds 10 to the inherited niceness, within its allowed range. The number is not a CPU percentage.

In the example, COMMAND is ps: we inspect the priority of the command we just started. No background processes or saved PID variables are needed.

The concepts that matter

1. The CPU executes instructions

The CPU (Central Processing Unit) does the computational work of running programs. Memory holds code and data; CPU time lets a program act on them.

A process can remain in memory while using almost no CPU. A server waiting for a request and a worker calculating a result therefore have different resource needs.

2. The scheduler shares CPU time

A thread is a sequence of execution within a process. A process can have one or several threads. Linux’s scheduler decides which runnable threads receive time on the available logical CPUs.

When more threads want to run than can execute at once, some must wait their turn. A sleeping thread normally does not compete for CPU time until it wakes.

More CPUs let more work run at once, but they do not automatically make one thread run in parallel. The application must be able to divide its work.

3. CPU usage measures activity, not health

In Linux top, a process at 100% CPU is using the full capacity of approximately one logical CPU. A multithreaded process can use several logical CPUs simultaneously, so its value can exceed 100%. For example, on a machine with eight logical CPUs, one process at 100% uses roughly one eighth of the machine’s total CPU capacity.

Focus on these process columns:

• %CPU: how much CPU capacity the process used during the most recent measurement period. Around 100% means it kept one logical CPU busy; 200% means roughly two logical CPUs.
• TIME+: the total time the CPU has spent executing this process since it started. Time spent sleeping or waiting for network, disk, or user input is not included. For example, a process can exist for one hour but show only 0:05.00 if it has used five seconds of CPU time.
• S: state; R means running or ready to run, while S means sleeping.
• NI: niceness, the scheduling preference explained next.

High CPU use can mean useful work. Low CPU use can mean a slow application is waiting on a database or network. Compare usage with response times and completed work before deciding there is a problem.

4. Niceness is a preference, not a limit

For ordinary workloads, niceness influences how CPU time is shared under competition. Its range is -20 to 19: a higher number means lower priority. The usual starting value is 0, inherited from the process that starts the command.

nice -n 10 normally changes that starting value from 0 to 10. A lower-priority process can still fully occupy a CPU when capacity is available.

Niceness neither caps CPU usage nor guarantees response time. It changes scheduling preference; enforceable CPU limits are a separate mechanism.

One small example

Optional: use one Bash terminal on Linux with procps top and ps. No administrator access is needed.

top -d 1

Wait for two refreshes. Pick a process and compare its %CPU, TIME+, and state. Your readings depend on the current workload; a quiet machine may show very little activity. Press q to return to the shell, then run:

nice -n 10 ps -o pid,ni,comm

Find the row whose command is ps and look at its NI value. NI means niceness. If your shell has the usual niceness value of 0, nice -n 10 starts ps with a niceness value of 10. A higher niceness value gives the process lower scheduling priority when it competes with other processes for CPU time.

Only the new ps process receives this value; the shell that started it remains at niceness 0. Because ps only displays information and immediately exits, this example confirms that nice changed the new process’s setting. It does not show the practical effect of that setting under real CPU competition.

No workload is left running and no cleanup is needed.

Keep this idea: the scheduler gives runnable work CPU time; top shows usage, while niceness influences priority rather than imposing a limit.