Fast switching of threads between cores

Abstract

We address the software costs of switching threads between cores in a multicore processor. Fast core switching enables a variety of potential improvements, such as thread migration for thermal management, fine-grained load balancing, and exploiting asymmetric multicores, where performance asymmetry creates opportunities for more efficient resource utilization. Successful exploitation of these opportunities demands low core-switching costs. We describe our implementation of core switching in the Linux kernel, as well as software changes that can decrease switching costs. We use detailed simulations to evaluate several alternative implementations. We also explore how some simple architectural variations can reduce switching costs. We evaluate system efficiency using both real (but symmetric) hardware, and simulated asymmetric hardware, using both microbenchmarks and realistic applications.

Fast thread migration via cache working set prediction

“…While those works used hardware support to implement scheduling and time-sharing policies, we use it simply for adding and removing threads from cores. Traditional software-driven migration has much higher overhead, which would dominate cache migration costs; we believe that direct OS involvement in all thread movement is ceasing to be a viable model, but even the OS overhead for migration can be significantly reduced from current levels [35].…”

Keep net working - on a dependable and fast networking stack

“…Current hardware trends suggest that the number of cores will continue to rise [2], [3], [23], [29], [35], [36] and that the cores will specialize [31], [39], [41], for example for running system services, single threaded or multithreaded applications. As a result, our view on processor cores is changing, much like our view on memory has changed.…”

Improving Server Performance on Multi-cores via Selective Off-Loading of OS Functionality

“…The conservative scheme is based on the thread migration time of approximately 5,000 cycles for an unmodified Linux 2.6.18 kernel. Proposals exist that could improve this delay to below just below 3,000 cycles on our target machine [22].…”

“…Each graph shows a static off-loading threshold N on the X-axis and a different curve for various one-way off-loading latencies. Evaluating multiple off-loading latencies is important because they are highly implementation dependent and can range from 5,000 cycles in current operating system implementations, down to just a few hundred cycles in some recent research proposals [22]. Figure 4 helps identify 3 major trends about OS off-loading.…”