the run queue
At any instant, most tasks on a system are not actually trying to run - they are blocked, waiting for a keystroke, a disk read, or a network packet. Only a few are runnable: ready to use a CPU right now if one were free. The run queue is the kernel's list of exactly those runnable tasks - the waiting line of work that the scheduler picks from. When the scheduler asks 'who should run next?', it is choosing from the run queue.
The lifecycle of a task moving through it is the clearest way to understand it. A task is in the run queue when it is runnable. The scheduler picks one to run on a CPU. If that task blocks - say it calls read() and the data is not ready - the kernel removes it from the run queue and the task sleeps; it is not wasting scheduler attention while it waits. Later, when its data arrives (an interrupt wakes it), the kernel puts it back on the run queue, runnable again, and the scheduler will get to it. So the run queue's membership constantly changes as tasks block and wake. On a multi-core machine, modern kernels keep a separate run queue per CPU (so cores do not all contend on one shared list), and a load balancer occasionally migrates tasks between them to keep the cores evenly busy.
Why the concept clarifies so much: it pins down what 'the scheduler chooses from' and separates two very different states. A task using lots of CPU and a task blocked on I/O are both 'running' in loose speech, but only the first is in the run queue; the blocked one is off it entirely until woken. This is also why load average on Unix counts runnable (and uninterruptible) tasks - it is essentially measuring how long the run queues are, i.e. how much work is contending for CPUs. Note that 'queue' is loose terminology: a modern run queue is often not a simple first-in-first-out line but a more elaborate structure (Linux's CFS used a red-black tree ordered by how little CPU each task has had), so do not picture a strict FIFO.
task calls read(), no data -> kernel removes it from the run queue, it sleeps. data arrives (IRQ) -> kernel wakes it, puts it back on the run queue -> scheduler eventually picks it. Blocked tasks are NOT in the run queue.
Only runnable tasks sit in the run queue; blocking removes a task from it, waking puts it back. The scheduler only ever chooses from this set.
'Queue' is loose: a modern run queue may be a tree or other structure, not a strict FIFO line (Linux CFS used a red-black tree ordered by accumulated runtime). The key invariant is that only runnable tasks are in it - a task blocked on I/O is off the run queue entirely until an event wakes it.