# CAL: Core-Aware Lock for the big.LITTLE Multicore Architecture
## 1 Introduction  
The single-core CPU (Central Processing Unit) performance has stagnated over recent years, and CPU manufacturers have turned to developing multicore processors. For the early multicore processors, the cores are symmetric, and the performance is the same as each other [1, 2], which means that each core has the same computation ability and energy consumption characterization. However, as the core number increases from 2 to 8 or more, the overall chip power consumption also increases and induces high costs for the data center and a sharp decrease in the standby time of the battery-powered embedded device (e.g., mobile phone). In order to trade-off the performance and lifetime of embedded devices, ARM (Advanced RISC Machine), AMD (Advanced RISC Machine), and Intel have devoted themselves to developing asymmetric multicore processors (e.g., 13 th Gen Intel (R) Core (TM) CPU, ARM A15 CPU), which contain high-performance cores (namely big core) and power-saved cores (namely little core). The ideal scenarios of big.LITTLE multicore architecture is that the big core runs computing-intensive tasks, and the little core runs less computing-intensive tasks. However, it's impractical for OS (Operating System) to schedule multiprocessing programs on only big cores or little cores [34]. The existing scheduling strategies, when executing scheduling tasks, tend to overlook the disparities among cores. As a result, the multiprocessing programs are randomly assigned to both big and little cores. When big and little cores collaborate on task processing, and locks are required to sync data between cores. Note that locks are employed by OS to synchronize data between processes and achieve mutually exclusive access to critical resources. These existing lock algorithms are designed and optimized to meet the specified hardware topology, e.g., the hierarchical lock is proposed for NUMA (Non-Uniform Memory Access) architecture to reduce cross-node communication overhead, and tas (Test-And-Test-And-Set) lock is proposed to mitigate the frequent cache line invalidates caused by atomic instructions. Tas lock is a spinlock algorithm used in concurrent programming, particularly in environments where multiple threads need to access shared resources in a mutually exclusive manner to prevent race conditions. It's an optimization over the traditional Test-and-Set lock, designed to reduce the contention caused by spinning (continuous checking) when the lock is already held. Spinlock constitute a simple synchronization primitive wherein, upon a thread's attempt to acquire a lock already held by another thread, instead of immediately relinquishing its CPU timeslice, the thread engages in a continuous loop of checks (spinning) until the lock becomes available. Ticket locks manage access to the lock through a queueing mechanism; each thread requesting the lock obtains an incrementally increasing \"ticket\" number and subsequently awaits its turn to acquire the lock as indicated by its ticket number being called. Cptltkt lock realizes a queued lock scheme, encompassing both global partitioned ticketing and local ticketing mechanisms for lock management. In the big.LITTLE multicore architecture, due to the performance gap between big core and little core, big core executes the same critical section faster than little one, which leads to the non-scalability of the inherent fairness of traditional locks. To depict the lock fairness issue brought by existing lock locks (i.e., core-unaware lock) in the big.LITTLE multicore architecture, we have experimented with observing the relationship between lock throughout, tail latency, and core type. The lock algorithms adapted in the experiment are from the LiTL library, which enables transparent replacement of Pthread mutex lock operations in Linux OS and allows plugging in different lock algorithms under a common API (Application Programming Interface). Figure 1 shows traditional locks' performance and latency breakdown in the big.LITTLE Multicore Architecture.