an interrupt service routine
When the CPU's doorbell (an interrupt) rings, something has to actually answer the door. An interrupt service routine is that answerer: a specific piece of kernel code that runs in response to a particular interrupt, deals with the event, and then lets the interrupted program continue. Different events have different handlers — one for the disk, one for the keyboard, one for the timer — and the CPU picks the right one automatically.
Concretely, here is how the right handler is found and run. The CPU keeps a table called the interrupt vector (on x86, the interrupt descriptor table) that maps each interrupt number to the address of its handler. When interrupt number k fires, the CPU saves the running program's essential state, switches to kernel mode, and jumps to the handler whose address sits at entry k. The handler must do its work quickly: read why the interrupt happened from the controller's status register, acknowledge the device so it stops asserting the line, move or note the relevant data, and possibly wake a process that was waiting. Then it returns, the CPU restores the saved state, and the interrupted program resumes. Because a handler may itself be interrupted by a higher-priority interrupt, and because it runs in a borrowed context, it must avoid slow operations and must not call routines that could block or sleep.
Why it matters: the ISR is where the OS meets a hardware event in real time, so it has tight rules. It should be short, since while it runs other work (and often other interrupts) may be held off. This pressure to keep handlers brief is precisely why the long, non-urgent part of the response is deferred to a bottom half (a softirq, tasklet, or work queue) that runs later with interrupts enabled, leaving only the truly time-critical part in the ISR itself.
The keyboard ISR runs the instant you press a key: it reads the scan code from the controller's data register, tells the controller it has been served, places the code into the kernel's input buffer, and returns — usually within a few microseconds.
Found via the interrupt vector, it handles the event fast and returns to the interrupted code.
An ISR runs in a constrained context: it cannot safely sleep or block, because there is no normal process to put to sleep. Anything that might wait must be pushed to the bottom half — putting slow work in the ISR is a classic kernel bug.