Interrupts & verzögerte Arbeit

Warum Interrupts?

Ein Gerät ist meist um Größenordnungen langsamer als die CPU. Der Kernel könnte natürlich immer wieder nachfragen, ob schon Daten da sind (Polling). Damit würde er aber Rechenzeit verschwenden und trotzdem verspätet reagieren. Stattdessen meldet sich das Gerät selbst, mit einem InterruptInterruptSignal eines Geräts (oder der CPU selbst), das den laufenden Code unterbricht, damit der Kernel ein Ereignis behandeln kann.. Die CPU kann in der Zwischenzeit andere Tasks ausführen oder Strom sparen.

In Kapitel 2 haben wir die drei Wege in den Kernel kennengelernt. Interrupts sind der einzige davon, der asynchron ist: Er kann zwischen zwei beliebigen Befehlen eintreffen, mitten in einem Benutzerprogramm und, sofern nicht gesperrt, auch mitten im Kernel. Neben Geräte-Interrupts gibt es:

• Timer-Interrupts, die den Takt für Zeitmessung und Scheduler liefern,
• Inter-Processor Interrupts (IPIs), mit denen CPUs sich gegenseitig benachrichtigen, etwa für TLB-Shootdowns (Kapitel 7) oder um einen Task auf einer anderen CPU aufzuwecken,
• Nicht maskierbare Interrupts (NMI), die sich nicht sperren lassen. Linux nutzt sie für Hänger-Erkennung (Watchdog) und Leistungsmessung.

Interrupt-Controller

Zwischen den Geräten und den CPU-Kernen sitzt auf x86 ein System von APICs (Advanced Programmable Interrupt Controller):

Bei MSI und MSI-X (Message Signaled Interrupts) löst ein PCIe-Gerät einen Interrupt aus, indem es eine kleine Nachricht an eine bestimmte Speicheradresse schreibt. Das bringt drei Vorteile:

• Es sind keine knappen Interrupt-Leitungen nötig.
• Ein Gerät kann sehr viele getrennte Interrupts haben (MSI-X: bis zu 2048).
• Jeder dieser Interrupts kann gezielt an eine bestimmte CPU gehen.

Eine moderne NVMe-SSD oder Netzwerkkarte hat deshalb oft eine Warteschlange pro CPU-Kern mit jeweils eigenem Interrupt. Jeder Kern bearbeitet dann „seine“ Anfragen, ohne mit anderen Kernen um Sperren konkurrieren zu müssen.

ARM-Systeme verwenden statt APICs den GIC (Generic Interrupt Controller), das Prinzip ist dasselbe.

Der Weg eines Interrupts

Handler registrieren

Ein Treiber meldet seinen Handler mit request_irq() an:

static irqreturn_t meinegeraet_irq(int irq, void *dev_id)
{
	struct meinegeraet *dev = dev_id;
	u32 status = readl(dev->regs + STATUS);

	if (!(status & IRQ_PENDING))
		return IRQ_NONE;              /* nicht von uns – geteilte Leitung */

	writel(status, dev->regs + STATUS);   /* Interrupt am Gerät bestätigen */
	schedule_work(&dev->work);            /* eigentliche Arbeit später erledigen */
	return IRQ_HANDLED;
}

/* bei der Initialisierung des Treibers */
err = request_irq(dev->irq, meinegeraet_irq, IRQF_SHARED, "meinegeraet", dev);

Der Rückgabewert sagt dem Kernel, ob der Handler sich zuständig fühlte. Meldet über längere Zeit kein Handler IRQ_HANDLED, schaltet der Kernel den Interrupt als „verwaist“ ab („nobody cared“), damit ein defektes Gerät das System nicht lahmlegt.

Top Half und Bottom Half

Während ein Interrupt-Handler läuft, sind auf dieser CPU weitere Interrupts gesperrt. Jede Mikrosekunde im Handler verzögert also andere Geräte und den Timer. Linux teilt die Arbeit deshalb auf:

• Die Top Half ist der eigentliche Interrupt-Handler. Sie erledigt nur das zeitkritische Minimum: das Gerät bestätigen, Daten sichern, die nicht verloren gehen dürfen, und die restliche Arbeit einplanen.
• Die Bottom Half erledigt alles Weitere später, mit freigegebenen Interrupts.

Für die Bottom Half gibt es mehrere Mechanismen:

Softirqs

SoftirqsSoftirqFest definierte Art aufgeschobener Kernel-Arbeit, die direkt nach einem Interrupt oder im Thread ksoftirqd läuft, etwa für Netzwerkpakete oder Timer. Darf nicht schlafen. sind die schnellste Form der Bottom Half. Es gibt genau zehn, fest im Quellcode definiert (include/linux/interrupt.h↗):

enum {
	HI_SOFTIRQ = 0,   /* hochpriore Tasklets */
	TIMER_SOFTIRQ,    /* abgelaufene Timer */
	NET_TX_SOFTIRQ,   /* Netzwerk: Senden */
	NET_RX_SOFTIRQ,   /* Netzwerk: Empfangen */
	BLOCK_SOFTIRQ,    /* Abschluss von Block-I/O */
	IRQ_POLL_SOFTIRQ,
	TASKLET_SOFTIRQ,  /* normale Tasklets */
	SCHED_SOFTIRQ,    /* Lastausgleich des Schedulers */
	HRTIMER_SOFTIRQ,  /* hochauflösende Timer */
	RCU_SOFTIRQ,      /* RCU-Verarbeitung (Kapitel 9) */
	NR_SOFTIRQS
};

Ein Interrupt-Handler markiert einen Softirq mit raise_softirq() als „anstehend“. Ausgeführt wird er spätestens beim Verlassen des Interrupts in handle_softirqs↗. Weil derselbe Softirq gleichzeitig auf mehreren CPUs laufen kann, müssen seine Handler sorgfältig synchronisiert sein. Dafür skalieren sie sehr gut.

Kommen ständig neue Softirqs nach, etwa unter hoher Netzwerklast, würden normale Tasks nie mehr an die Reihe kommen. Der Kernel begrenzt die Bearbeitung deshalb auf 2 ms bzw. 10 Durchläufe und übergibt den Rest an den Kernel-Thread ksoftirqd/N der jeweiligen CPU. Dieser wird vom Scheduler wie ein normaler Task behandelt.

Workqueues

Eine WorkqueueWorkqueueMechanismus, um Arbeit an Kernel-Threads (kworker) zu übergeben. Die Arbeit läuft im Prozesskontext und darf schlafen. nimmt Arbeitsaufträge (struct work_struct) entgegen und lässt sie von Kernel-Threads (kworker/…) im Prozesskontext ausführen. Dort darf der Code schlafen, Mutexe nehmen und I/O abwarten:

static void meinegeraet_work(struct work_struct *work)
{
	struct meinegeraet *dev = container_of(work, struct meinegeraet, work);

	mutex_lock(&dev->lock);       /* hier erlaubt – wir sind im Prozesskontext */
	/* … Daten verarbeiten, ggf. auf das Gerät warten … */
	mutex_unlock(&dev->lock);
}

INIT_WORK(&dev->work, meinegeraet_work);   /* einmalig */
schedule_work(&dev->work);                  /* z. B. aus dem Interrupt-Handler */

Die Workqueue-Infrastruktur („concurrency managed workqueues“) verwaltet einen Pool von Worker-Threads pro CPU. Sie startet nur so viele Threads, wie nötig sind, um die CPU ausgelastet zu halten. Blockiert ein Auftrag, übernimmt ein weiterer Worker die nächsten.

Threaded IRQs

Bei einem Threaded IRQ registriert der Treiber zwei Funktionen mit request_threaded_irq(): einen kurzen Handler, der im Interruptkontext läuft und IRQ_WAKE_THREAD zurückgibt, und eine Thread-Funktion, die anschließend in einem eigenen Kernel-Thread irq/<nr>-<name> ausgeführt wird. Dieser Thread hat eine Echtzeit-Priorität, reagiert also schnell, darf aber schlafen.

Mit PREEMPT_RT (Kapitel 6) werden fast alle Interrupt-Handler automatisch als Threads ausgeführt. Dadurch lassen sie sich verdrängen und priorisieren, und genau das macht vorhersagbare Reaktionszeiten möglich.

Zeit und Timer

Der Tick und jiffies

Klassischerweise lässt der Kernel einen Timer in festen Abständen einen Interrupt auslösen, den Tick. Die Frequenz HZ wird beim Bauen des Kernels festgelegt. Typisch sind 250 oder 1000 pro Sekunde. Bei jedem Tick

• erhöht der Kernel den Zähler jiffiesjiffiesZähler des Kernels, der mit jedem Timer-Tick um eins erhöht wird. Die Tickrate HZ liegt je nach Konfiguration zwischen 100 und 1000 pro Sekunde.,
• prüft er, ob Timer abgelaufen sind,
• rechnet er dem laufenden Task Rechenzeit an und lässt den Scheduler prüfen, ob die Zeitscheibe abgelaufen ist (sched_tick()).

Timer im Kernel

Für Zeitüberschreitungen gibt es zwei Arten von Timern:

• Klassische Timer (struct timer_list) haben eine Auflösung von einem Jiffy. Sie liegen in einem Timer-Rad (timer wheel) aus 8 bis 9 Ebenen mit je 64 Fächern. Nahe Zeitpunkte werden fein, ferne grob einsortiert. Einfügen und Entfernen geschieht so in konstanter Zeit. Die meisten dieser Timer (Netzwerk-Zeitüberschreitungen, Watchdogs) werden übrigens gelöscht, bevor sie ablaufen.
• Hochauflösende Timer (hrtimer) arbeiten in Nanosekunden und werden in einem Rot-Schwarz-Baum nach Ablaufzeit sortiert. Sie stecken hinter nanosleep(), Timeouts von poll() und epoll, POSIX-Timern und dem Scheduler-Tick selbst.

Darunter liegen zwei Abstraktionen für die Hardware: clocksource (eine fortlaufende Zeitquelle zum Ablesen, auf x86 meist der TSC-Zähler der CPU) und clockevent (ein Gerät, das zu einem bestimmten Zeitpunkt einen Interrupt auslöst, etwa der Timer des Local APIC).

Interrupts verteilen und abschalten

Verteilung: Über /proc/irq/<nr>/smp_affinity_list lässt sich festlegen, welche CPUs einen Interrupt bearbeiten dürfen. Der Dienst irqbalance verteilt Interrupts automatisch nach Last. Für Geräte mit einer Warteschlange pro CPU legt der Treiber die Zuordnung meist selbst fest (managed interrupts).

Abschalten: Manchmal muss Kernel-Code verhindern, dass ein Interrupt dazwischenkommt, etwa wenn er Daten bearbeitet, die auch ein Interrupt-Handler anfasst. Dafür gibt es:

Das Sperren von Interrupts auf einer CPU schützt nicht vor anderen CPUs. Dafür braucht man zusätzlich Sperren. Wie beides zusammenspielt, zeigt Kapitel 9.

Selbst ausprobieren

# Zähler je Interrupt und CPU – zweimal ausführen und vergleichen
cat /proc/interrupts

# Live: welche Zähler steigen gerade? (Strg+C beendet)
watch -n1 -d "grep -E 'CPU|nvme|eth|enp|wlp|LOC|RES|TLB' /proc/interrupts"

# Softirq-Zähler je CPU
cat /proc/softirqs

# Kernel-Threads für Softirqs, Threaded IRQs und Workqueues
ps -eo pid,cls,rtprio,comm | grep -E 'ksoftirqd|irq/|kworker' | head -n 20

# Welche CPUs bearbeiten Interrupt Nr. 0 (Timer)? Beliebige Nummer aus /proc/interrupts einsetzen
cat /proc/irq/0/smp_affinity_list

# Tickrate und Zeitquelle
grep -E '^CONFIG_HZ=|^CONFIG_NO_HZ' /boot/config-$(uname -r)
cat /sys/devices/system/clocksource/clocksource0/current_clocksource