Riassunto analitico
Le piattaforme SoC eterogenee (HeSoC) sono estremamente utilizzate al giorno d'oggi. Molti settori usano HeSoC, come quello industriale, medico, o telefonico. Questi sistemi sono solitamente composti da un general-purpose processore multi-core, e da vari acceleratori hardware, creati per eseguire specifiche operazioni velocemente ed efficientemente. Gli HeSoC sono ristretti ed efficienti, ma grazie alla loro eterogeneità, possono soddisfare workload intensi. In generale, vengono usati o General-Purpose Graphical Processing Unit (GPGPU), o Field Programmable Gate Array (FPGA). La diffusione di questi sistemi, porta anche nuove sfide.
Solitamente, viene usata un'architettura in cui gli acceleratori sono connessi tramite un bus condiviso alla DRAM del sistema. Purtroppo, questa risulta essere posta sotto stress, a causa della quantità crescente di core che risultano essere interconnessi. Questo può portare a un incremento significativo nel tempo di esecuzione dei task, e diminuisce la banda a disposizione dei singoli attori, impedendo di prevedere la durata dell'esecuzione di certe operazioni nel sistema. Visto che gli acceleratori usano più banda, i task della CPU risultano subire rallentamenti sproporzionati (sotto certe circostanze, risultano essere di un fattore 16).
Gli approcci dello stato dell'arte per portare garanzie alle tempistiche su tali piattaforme sono spesso troppo conservativi, consentendo solo a un attore alla volta di accedere alla memoria, sotto-utilizzando severamente la banda. Runtime Bandwidth Regulation (RBR) è una tecnica che è stata proposta di recente per soddisfare richieste di Qualità del Servizio (QoS) per task CPU sensibili a rallentamenti, utilizzando il più possibile il resto della banda disponibile. RBR diminuisce le richieste degli acceleratori, limitando la loro banda, e facendo sì che i task CPU possano eseguire con interferenza controllata sulla memoria, per soddisfare i requisiti di QoS. Il sistema, indipendente dalla piattaforma, può essere visto come una scatola nera con la Cluster Load Intensity (CLI) come parametro, un fattore di rallentamento per i task dell'acceleratore. Questo valore diminuisce la banda consumata dall'acceleratore, e fa sì che i task CPU subiscano meno latenza. Molte implementazioni RBR sono sistemi proof-of-concept che operano usando carichi sintetici per CPU e Acceleratori con accesso Bare-Metal (senza Sistema Operativo).
Affinché questa tipologia di sistema sia più largamente adottata, Gabriele Felici sviluppò un module del kernel di Linux per RBR. Limitava l'interferenza subita dalla CPU tramite il parametro CLI, cambiandolo durante l'esecuzione in base alla banda richiesta dai task.
Tuttavia l'implementazione era molto primitiva: poteva soddisfare richieste di QoS per task con runtime maggiore di 500 ms, e non supportava la possibilità che la banda cambiasse dinamicamente nel tempo per i task, o per gli acceleratori.
Questo lavoro introduce un nuovo Schema di Controllo, per migliorare il modulo del kernel Linux inizialmente creato da Gabriele.
Il nuovo algoritmo introdotto ha reso la velocità di convergenza verso la banda corrispondente alla QoS richiesta 9 volte superiore, e il passaggio a un sistema basato sui timer, ha reso il controllore 40 volte più reattivo.
|
Abstract
Nowadays, embedded computing is increasingly adopting Heterogeneous Systems-on-chip (HeSoC) as a reference architecture. Many applications involve HeSoC, like mobile, industrial, or medical sectors. These platforms are usually composed of a general-purpose multi-core processor useful for its flexibility, coupled with several hardware accelerators, each designed to perform a specific application task fast and in a very efficient way. HeSoCs are thought to be smaller and more energy-efficient, guaranteeing high-performance thanks to the heterogeneity of all the parts. Generally, an HeSoC includes an accelerator engine able to satisfy the needs of modern software applications, like a General-Purpose Graphics Processing Unit (GPGPU) or a Field Programmable Gate Array (FPGA); however, novel challenges are born with the diffusion of these systems.
These architectures typically rely on a shared-memory organisation, where several general-purpose processors and accelerators are interconnected through a shared bus to the main system DRAM. Unfortunately, as the number of compute engines grows into the chip, the main interconnected memory is used by more actors, which may lead to higher latency experienced by certain tasks due to the high number of concurrent accesses to the memory. Memory sharing significantly affects the tasks’ execution time and decreases per-actor bandwidth: as a result, timing is unpredictable in the system. Since the accelerators use much more bandwidth, this interference affects the CPU tasks disproportionately, as they can experience a severe slowdown (which has been measured to be up to 16 times under certain circumstances).
State of the art approaches to provide timing guarantees on such platforms are often too conservative, allowing a single actor at a time to access memory, which severely under-utilizes the available memory bandwidth. Runtime Bandwidth Regulation system (RBR) has been recently proposed as a technique to satisfy a certain quality of service (QoS) requirement on timing-sensitive CPU tasks, while at the same time using as much of the available shared memory bandwidth as possible. RBR can throttle memory requests from the accelerators, limiting their bandwidth and consequently allowing the CPU tasks to execute their own memory requests with controlled memory interference, which ultimately allows to satisfy the QoS requirement. The system is platform-independent and can be seen as a black box with a unique parameter as input, the Cluster Load Intensity (CLI), a throttling factor for the accelerator's tasks. Giving this value to the system reduces the accelerator's overall bandwidth usage and decreases CPU tasks latency. Most state-of-the-art RBR implementations are proof-of-concept systems that operate with synthetic CPU and accelerators workloads assuming bare-metal (i.e., OS-less) operation.
For this approach to be more widely adopted in real-life systems, a first important step was recently taken by Gabriele Felici, who developed a RBR Linux Kernel module. It limited the interference which the CPU was subject to by using the CLI parameter, and adjusting it in real-time through the measurement of the bandwidth requested by the tasks.
However, the system's implementation was very primitive: it could only satisfy QOS requirements for tasks executing for longer than 500 ms, and it didn't support the possibility for the bandwidth requested by either the tasks or the accelerators to dynamically change over time.
This work aims at introducing a new Control Scheme, to improve Gabriele's previous Linux Kernel module.
The new algorithm increased the convergence speed towards the bandwidth corresponding to the requested QoS by 9 times, and the switch to a timer-based system, increased the controller's reactiveness by 40 times.
|
