The context-switch overhead inflicted by hardware interrupts (and the enigma of do-nothing loops)

Abstract

The overhead of a context switch is typically associated with multitasking, where several applications share a processor. But even if only one runnable application is present in the system and supposedly runs alone, it is still repeatedly preempted in favor of a different thread of execution, namely, the operating system that services periodic clock interrupts. We employ two complementing methodologies to measure the overhead incurred by such events and obtain contradictory results.The first methodology systematically changes the interrupt frequency and measures by how much this prolongs the duration of a program that sorts an array. The overall overhead is found to be 0.5-1.5% at 1000 Hz, linearly proportional to the tick rate, and steadily declining as the speed of processors increases. If the kernel is configured such that each tick is slowed down by an access to an external time source, then the direct overhead dominates. Otherwise, the relative weight of the indirect portion is steadily growing with processors' speed, accounting for up to 85% of the total.The second methodology repeatedly executes a simplistic loop (calibrated to take 1ms), measures the actual execution time, and analyzes the perturbations. Some loop implementations yield results similar to the above, but others indicate that the overhead is actually an order of magnitude bigger, or worse. The phenomenon was observed on IA32, IA64, and Power processors, the latter being part of the ASC Purple supercomputer. Importantly, the effect is greatly amplified for parallel jobs, where one late thread holds up all its peers, causing a slowdown that is dominated by the per-node latency (numerator) and the job granularity (denominator). We trace the bizarre effect to an unexplained interrupt/loop interaction; the question of whether this hardware misfeature is experienced by real applications remains open.

Extending Summation Precision for Network Reduction Operations

“…Computing in NICs avoids potentially large context switching or wake up delays for local processors, as well as data transfer latencies between the NIC and the processor that are typically significantly longer than the few cycles to perform integer addition. Context switching requires µs [43], while waking up processors from deep sleep may require seconds [44], [45]. So the handful additional cycles required for extended precision and BigInts are negligible compared to the network time.…”

Accurate energy characterization of OS services in embedded systems

“…Besides, the OS memory paging represents a source of the indirect overhead since the context switch can occur in a memory page moved to the disk when there is no free memory. Prior research has shown that indirect context switch overheads [14], mainly the cache perturbation effect, are significantly larger than direct overheads.…”

Energy leakage in low power embedded operating systems using DVFS policy

“…Besides, the OS memory paging represents a source of the indirect overhead since the context switch can occur in a memory page moved to the disk when there is no free memory. Prior research has shown that indirect context switch overheads [9], mainly the cache perturbation effect, are significantly larger than direct overheads. We refer to the extra cache misses that occur as a result of the cache perturbation by context switching as context switch cache misses.…”