-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathstep3.tex
More file actions
12 lines (8 loc) · 5.95 KB
/
step3.tex
File metadata and controls
12 lines (8 loc) · 5.95 KB
1
2
3
4
5
6
7
8
9
10
11
12
After conducting the research summarized in Sections~\ref{sec:step1} and \ref{sec:step2}, we will have a set of energy-efficient real-time scheduling methods on heterogeneous computing platforms. This section discusses our implementation plan and evaluation work needed to assess which methods are preferable from the perspectives of overhead-conscious schedulability, runtime response times, and energy consumption.
\vspace{-2mm} \paragraph{Implementation plans.} We will implement our proposed resource allocation methods in real systems to evaluate their performance in practice. The OS platform will be LITMUS$^{\textrm{RT}}$~\cite{LITMUS}. As discussed earlier, our goal of using LITMUS$^{\textrm{RT}}$ is to have a useful experimental platform for evaluating overhead-conscious schedulability of our proposed scheduling methods.
As discussed earlier, ARM's big.LITTLE supports Linux. The two open-source scheduling modules, i.e., kernel switcher and global task scheduling~\cite{armscheduler}, can be patched to the Linux kernel. Thus, we will patch LITMUS$^{\textrm{RT}}$ to the Linux kernel running on big.LITTLE.
Each of our proposed methods will be implemented in LITMUS$^{\textrm{RT}}$ as a plugin component. (This implementation method allows users to switch between different scheduling policies at runtime.) %An interesting set of experiments would be to compare the timing and energy performance between our proposed methods and the native kernel switcher and global task scheduling methods on big.LITTLE.
To measure energy consumption, we will use the two currently available tools. The first tool is the ARM DS-5 Streamline tool set\cite{ARMDS5}, which is a performance analyzer that brings together system performance metrics, software tracing, statistical profiling and power measurement through user interface. The second tool is to the INA231 Current/Power monitor chip produced by TI \cite{israelssonenergy, INA231, hahnel2014heterogeneity}. The power data is obtained through measuring both the shunt voltage drops and bus supply voltage. The ODROID-XU3 board~\cite{ODROIDXU} powered by ARM big.LITTLE technology already integrates four INA231 monitors that can measure the energy data of the ``big'' cluster, ``LITTLE'' cluster, GPU, and memory \cite{hahnel2014heterogeneity}. We currently have a cluster of 12 ODROID-XU3s in our research lab for implementation and evaluation purposes.
We also intend to consider heterogeneous multicore platforms from other manufactures as well as those adopting similar heterogeneous system architectures. For instance, we plan to consider another two heterogeneous multicore architectures that are similar to big.LITTLE, i.e., NVIDIA's Tegra 3 SoC~\cite{KalEI} and Freescale's Vybrid SoC~\cite{VybridController}. Tegra 3 adopts a variable symmetric multiprocessing technology, which aims to minimize the active standby state power consumption but still deliver required performance. Tegra 3 includes an ARM's quard-core Cortex A9 processor for high performance and one companion CPU which is energy-efficient but delivers relatively low performance. The platform can save energy by scheduling less resource-demanding task to the companion CPU. Compared to big.LITTLE, Tegra 3 may yield a milder solution for energy saving and a smaller range for energy-performance tradeoff. Freescale's Vybrid SoC also applied asymmetric architecture, but for the purpose of separating user-interface workloads and real-time workloads. The platform consists of one ARM Cortex-A5 processor running Linux and one ARM Cortex-M4 core running real-time operating systems like freescale's MQX. A multicore communication protocol is designed to coordinate the interactions between the two processors. Compared to big.LITTLE architecture, the Vybrid architecture mainly deals with the conflicts between real-time and non-real-time workloads other than the tradeoff between energy and performance.
\vspace{-2mm} \paragraph{Overhead-conscious schedulability and energy studies.} A research focus herein is to sift through all resource allocation options identified in Sections~\ref{sec:step1} and \ref{sec:step2} through evaluating the performance with respect to schedulability and energy efficiency when practical scheduler-incurred overheads are considered. The overhead-conscious evaluation is important as a theoretically-sound scheduler may not perform well in practice. For example, although global scheduling approaches generally yield better theoretical schedulability tests with less capacity loss than partitioned approaches, they may perform worse than partitioned approaches due to the more frequent task preemption and migrations.
To evaluate the performance with respect to overhead-conscious schedulability and energy efficiency, we will follow a mature experimental process applied in many previous work \cite{BBBdissertation, clustered, bastoni2010, calandrino2007, johndissertation}. Actual system overheads will be gathered and considered in this process. Scheduling actions may incur various types of overheads, including costs due to scheduling decisions, context switch operations, task queue management, interrupt servicing, and preemption and migration. By implementing our proposed energy efficient heterogeneity-aware scheduling algorithms in LITMUS$^{\textrm{RT}}$, we will be able to gather these overheads under different approaches using millions of randomly generated task systems and benchmarks. After collecting overheads, we will factor them into task parameters and check the schedulability of all generated task systems. The outcome of this experimental process is a collection of schedulability graphs showing how different scheduling approaches perform and compare in light of real system overheads. Besides schedulability, energy consumption, response time bounds (analytically derived under our derived schedulability tests) and run-time response times are also important. We will also evaluate the proposed methods in terms of energy consumption, and maximum and average runtime response times.