Utility-based acceleration of multithreaded applications on asymmetric CMPs

Abstract

Asymmetric Chip Multiprocessors (ACMPs) are becoming a reality. ACMPs can speed up parallel applications if they can identify and accelerate code segments that are critical for performance. Proposals already exist for using coarsegrained thread scheduling and fine-grained bottleneck acceleration. Unfortunately, there have been no proposals offered thus far to decide which code segments to accelerate in cases where both coarse-grained thread scheduling and fine-grained bottleneck acceleration could have value. This paper proposes Utility-Based Acceleration of Multithreaded Applications on Asymmetric CMPs (UBA), a cooperative software/hardware mechanism for identifying and accelerating the most likely critical code segments from a set of multithreaded applications running on an ACMP. The key idea is a new Utility of Acceleration metric that quantifies the performance benefit of accelerating a bottleneck or a thread by taking into account both the criticality and the expected speedup. UBA outperforms the best of two state-of-the-art mechanisms by 11% for single application workloads and by 7% for two-application workloads on an ACMP with 52 small cores and 3 large cores.

An Analytical Framework for Estimating Scale-Out and Scale-Up Power Efficiency of Heterogeneous Manycores

“…In other words, it alternately accelerates threads on fast cores till all threads hit the barrier. Likewise, UBA [53] traces the bottleneck of slow threads include locks, barriers, pipeline, and serial section. It alternatively accelerates the bottlenecks of different applications on fast cores.…”

“…Prior scheduling methods focus on how to use the fast core to boost the performance of multi-threaded applications [52] [53]. CAMP (comprehensive scheduler for asymmetric multi-core processor) adopts BusyFCs strategy keeping the fast cores busy.…”

Kernel-to-User-Mode Transition-Aware Hardware Scheduling

“…Although fairness-aware scheduling strives to achieve fairness by running each logical core thread on each physical core type for an equal amount of time, the KUTHS scheduling instead tries to enhance these scheduling benefits by discovering and running the critical code sections on the larger cores. The difference between KUTHS and the state-of-the-art bottleneck acceleration techniques found in bottleneck identification and scheduling (BIS) 10 and utility-based acceleration (UBA) 11 is that KUTHS does not require any ISA extensions that impact code reusability.…”

“…KUTHS has hardware additions, including a transition bit on every core and a vector that holds all of the transition bits. However, in contrast to the low additional overhead needed by KUTHS, UBA requires the lagging thread identification, bottleneck identification, and acceleration coordination, 11 whereas BIS requires a bottleneck table whose entries correspond to a bottleneck, an acceleration index table augmented with each small core, and a scheduling buffer added to each large core. 10 KUTHS algorithm extension for many-core systems Now that we've explained the essence of the KUTHS algorithm, it is important to note the results in Table 1 before applying KUTHS on a many-core processor.…”

“…When schedulers could identify all or most of the critical section, using online or offline profiling or ISA extensions, they experienced the problem of threads piling up and waiting in the queue on the large core, and an increased number of unused small cores in the system. 3,10,11 This was especially noticeable in many-core systems running a large number of threads. Therefore, they had to incorporate additional software or hardware mechanisms to balance the workload.…”