## 2 Technological Background and Related Work
### The Kernel-Based Memory-Aware Load Balancing (kMLB) Mechanism  
Inter-node task migration is necessary for an operating system to balance the load between NUMA nodes, and migrating different tasks for inter-node load balancing incurs a different amount of remote memory access. As shown in Figure 2, migrating the first task in the source runqueue, i.e., Task#3, incurs 3-page remote memory access but migrating Task#10 incurs 5-page remote memory access. However, the unmodified Linux kernel always selects the first task that can be migrated to run on the destination core. It allows rapid selection, but the first task may not incur the least remote memory access after the inter-node migration. A previous study [4] shows that it is better to select the task that involves less remote memory access after migration. The kernel-based Memory-aware Load Balancing (kMLB) mechanism was proposed to select suitable tasks to migrate between nodes to allow better load balancing in the Linux kernel. The memory usage for each task on each node is tracked. Depending on a task's current running node, the physical pages that it occupies on each node are identified as local or remote. The load balancer then uses this information to determine the most suitable task for inter-node migration. In the Linux kernel, the Resident Set Size (RSS) [1] for one process is the number of page frames occupied by this process. The original RSS only tracks the total number of page frames that are occupied by each process. The kMLB mechanism modifies the kernel operations to track the RSS counters on each node for each process, including dynamic memory allocation and releases, demand paging, swapping, system calls, and inter-node page migration. The following details task selection policies that are used with the kMLB mechanism. For the example in Figure 2, Table 1 shows the selected task for each policy according to the specific metric used. * Total Min (TM) Policy [3] selects the task in the source core's runqueue with the minimal total memory size. It is possible to have the least influence caused by task migration since the selected one occupies the least amount of memory for access after migration. * Most Benefit (MB) Policy selects the task in the source core's runqueue that can reduce the maximum amount of remote memory access when migrated. This policy considers the memory that is occupied by each task on the source and destination nodes. The task with the maximum difference is selected. The following metric is used to select the target task with the maximum value, in which RSS\(p\)(i) is the RSS value for task \(p\) on NUMA node \(i\) and _dest_node_ and _src_node_ are the IDs for the destination and source NUMA nodes, respectively: \[\text{MB}_{p}=\text{RSS}_{p}(\textit{dest\_node})-\text{RSS}_{p}(\textit{src\_ node})\]
* Best Cost-Effectiveness (BCE) Policy selects the task in the source core's runqueue for which inter-node migration is the most cost-effective. Based on the MB policy, the BCE policy also considers the maximum cost of page migration, which is the amount of memory occupied by one task on the source node. The selected task is the one that can reduce the maximum remote memory access relative to the maximum migration  
\begin{table} \begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Policy**} & \multicolumn{3}{c}{**Tasks Waiting in the Source Core’s Runqueue**} & \multirow{2}{*}{**Selected Task**} \\ \cline{2-2} \cline{4-5}  & **Task\#3** & **Task\#9** & **Task\#10** & \\ \hline First-Fit & N/A & N/A & N/A & Task\#3 \\ TM & \(3+7=10\) & \(3+3=6\) & \(5+10=15\) & Task\#9 \\ MB & \(7-3=4\) & \(3-3=0\) & \(10-5=5\) & Task\#10 \\ BCE & \((7-3)/3=1.333\) & \((3-3)/3=0\) & \((10-5)/5=1\) & Task\#3 \\ \hline \hline \end{tabular}   
* Total Min (TM) Policy [3] selects the task in the source core’s runqueue with the minimal total memory size. It is possible to have the least influence caused by task migration since the selected one occupies the least amount of memory for access after migration.