Adaptive Runtime Management for Workload Optimization on Heterogeneous Edge Devices

UNIVERSITÀ DEGLI STUDI DI SASSARI Dipartimento di Ingegneria Corso di Laurea in Ingegneria Informatica Gestione Adattiva a Runtime per l’Ottimizzazione dei Workload su Dispositivi Edge Eterogenei Relatore: Dott. Claudio Rubattu Università degli Studi di Sassari Laureando: Christian Madeddu Anno accademico 2024-2025 Prefazione La presente prefazione accompagna la prova finale del Corso di Laurea in Ingegneria Informatica, svolta sotto la supervisione dell’Università degli Studi di Sassari nell’ambito del progetto europeo MYRTUS. Il progetto mira a integrare le risorse computazionali distribuite tra i diversi livelli infrastrutturali (edge, fog e cloud) in linea con l’iniziativa europea CloudEdgeIOT, così da creare un ecosistema dinamico e ad alte prestazioni capace di far cooperare componenti eterogenei. Il contributo qui presentato si concentra sul Node Manager, il componente incaricato di ottimizzare l’esecuzione delle applicazioni sui dispositivi edge. A esso è richiesto di prendere decisioni adattive basate sia sulle caratteristiche dei carichi di lavoro sia sulle proprietà hardware del dispositivo, con l’obiettivo di modulare le condizioni operative e migliorare l’efficienza complessiva, ad esempio riducendo il consumo energetico. Il raggiungimento di questo obiettivo è reso sempre più complesso da due fattori emergenti. Da un lato, i carichi di lavoro all’edge diventano più articolati: spesso fondati su modelli di intelligenza artificiale e distribuiti tramite container. Dall’altro, la varietà e l’eterogeneità dei dispositivi edge continua a crescere, favorendo piattaforme miste in grado di unire flessibilità ed efficienza. Tale eterogeneità risulta particolarmente adatta al paradigma di orchestrazione previsto in MYRTUS. Nel progetto, la piattaforma hardware dei nodi edge si basa soprattutto su un processore ARM affiancato da logica programmabile (cioè l’FPGA), una combinazione che permette di sfruttare sia il sistema operativo per l’orchestrazione sia l’accelerazione hardware. Questa scelta offre un buon equilibrio tra elasticità e prestazioni, ma richiede un controllo accurato dei carichi, specialmente quando l’esecuzione coinvolge congiuntamente CPU e FPGA. Per queste ragioni, e dato che la CPU rappresenta una quota significativa del consumo energetico (ospitando sistema operativo, orchestratore e parte dei carichi), questo lavoro propone una versione software del Node Manager in grado di i) monitorare l’utilizzo del processore ARM e ii) impostarne la frequenza operativa per ridurre il consumo complessivo durante l’esecuzione. L’approccio è stato valutato tramite la costruzione di un dataset di misure energetiche raccolte sulla AMD Kria KV260, variando sia la frequenza operativa della CPU sia le tipologie e configurazioni di carichi containerizzati. Dal confronto con la gestione predefinita del sistema operativo e con un modello decisionale basato su una fase di pre-caratterizzazione, il Node Manager proposto dimostra di ridurre il consumo energetico del 6,51% e dello 0,48% per carichi eseguiti solo su CPU, e del 4,89% e dell’1,35% per carichi CPU–FPGA. Questi risultati, seppur preliminari e limitati al controllo della frequenza della CPU, evidenziano come un approccio adattivo alla gestione di nodi edge eterogenei possa migliorare l’efficienza nei contesti che impiegano l’orchestrazione tramite container. Abstract This abstract pertains to the final project of the Bachelor’s Degree in Computer Engineering, carried out under the supervision of the University of Sassari within the European MYRTUS initiative. MYRTUS aims to integrate computational resources across different infrastructure layers (edge, fog, and cloud) in alignment with the EU CloudEdgeIOT initiative. The MYRTUS’s goal is to enhance synergy among heterogeneous components to build dynamic, high-performance infrastructures. This work focuses specifically on the Node Manager, the component responsible for optimizing workload execution on edge devices. The Node Manager must make adaptive decisions that adjust operational conditions based on both workload characteristics and device hardware parameters, with the objective of improving edge level efficiency in terms of energy consumption. Achieving this goal has become increasingly challenging due to two emerging factors. First, edge workloads are becoming more complex: they increasingly rely on AI-based models and are deployed through container orchestration. Second, the ecosystem of edge devices has become more diverse, frequently adopting heterogeneous hardware platforms to balance flexibility and efficiency. This aspect aligns well with MYRTUS’s vision of container-based workload orchestration. In MYRTUS, heterogeneous edge hardware typically combines an ARM processor with programmable logic (i.e., FPGA), enabling orchestration through the operating system alongside hardware acceleration. While this configuration strikes a promising balance between adaptability and performance, it also demands careful execution management, especially when workloads span both CPU and FPGA. Given that the CPU accounts for a significant amount of total power consumption (running the operating system, container orchestrator, and part of the workloads), this work proposes a software implementation of the Node Manager capable of i) monitoring ARM CPU usage and ii) selecting the processor’s operating frequency to reduce the workload’s energy impact. The implementation was evaluated through a dataset of energy measurements collected on an AMD Kria KV260 board across different CPU frequencies and various containerized workload types and configurations. Compared with the default operating system strategy and with a decision model based on pre-characterization, the implemented Node Manager achieves energy savings of 6.51% and 0.48% for CPU-only workloads, and 4.89% and 1.35% for combined CPU–FPGA execution. Although preliminary and limited to CPU frequency selection, these results demonstrate that adaptive management of heterogeneous edge nodes can effectively enhance efficiency in scenarios that rely on container-based workload orchestration. Indice 1 Introduzione 1 1.1 Motivazioni e obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Contributo del lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Struttura del manoscritto . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Hardware e Software Utilizzati 3 2.1 AMD Kria KV260 Vision AI Starter Kit . . . . . . . . . . . . . . . . 3 2.2 Docker................................... 4 2.3 Lightweight Kubernetes K3s . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 ScikitLearn................................ 6 3 Implementazione del Node Manager 7 3.1 Struttura del Node Manager . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Deployment e monitoraggio dei workload . . . . . . . . . . . . . . . . 8 3.3 Creazione dell’albero decisionale . . . . . . . . . . . . . . . . . . . . . 9 4 Risultati 13 4.1 Preparazione per il Deployment . . . . . . . . . . . . . . . . . . . . . 13 4.2 Workload e parametri utilizzati . . . . . . . . . . . . . . . . . . . . . 15 4.3 Test sulla Kria KV260 e risultati ottenuti . . . . . . . . . . . . . . . . 16 5 Conclusione 19 I Elenco delle figure 1 AMD Kria KV260 Vision AI Starter Kit . . . . . . . . . . . . . . . . 3 2 SoMKriaK26............................... 4 3 Docker e Macchine Virtuali a confronto . . . . . . . . . . . . . . . . . 5 4 Schema del Node Manager . . . . . . . . . . . . . . . . . . . . . . . . 7 5 Schema delle fasi di pod_monitor.py . . . . . . . . . . . . . . . . . . 8 6 Schema delle fasi di tree.py . . . . . . . . . . . . . . . . . . . . . . . . 10 7 Uno degli alberi che compongono la foresta decisionale . . . . . . . . 11 8 Dettaglioalbero.............................. 11 9 Accuratezze dei profili e del modello basato su alberi decisionali e differenzetradiloro. ........................... 17 10 Risparmio energetico con workload CPU e workload CPU-FPGA rispetto ai profili fissi e al caso migliore. . . . . . . . . . . . . . . . . 18 II 1 Introduzione Questo progetto mira alla realizzazione del Node Manager del progetto europeo MYRTUS [1]. Comprendente 14 partner provenienti da 8 nazioni europee, MYRTUS si propone di sviluppare un nuovo paradigma per la gestione del computing continuum, con metodologie e strumenti per l’esecuzione dei nodi e la portabilità dell’elaborazione su un’infrastruttura edge-fog-cloud. L’obiettivo è dunque quello di diventare un punto di riferimento nel computing continuum fornendo le tecnologia Myrtus ad aziende e startup riducendone tempi e costi di sviluppo. Si occupa, inoltre, di risparmio di risorse ed energia e di combattere l’obsolescenza dei dispositivi. MIRTO, un motore cognitivo basato sull’intelligenza artificiale, rappresenta il nucleo del progetto e si occupa di orchestrarne l’infrastruttura. 1.1 Motivazioni e obiettivi Alla base di questo lavoro c’è la necessità di ottimizzare l’esecuzione di workload su dispositivi edge eterogenei come la Kria KV260 Vision AI Starter Kit utilizzata nel progetto Myrtus. Dispositivi di questo tipo sono utili grazie alla possibilità di fungere da acceleratori hardware per i carichi di lavoro diminuendone tempi di esecuzione e consumi[9]. Spesso, inoltre, per massimizzare le prestazioni vengono utilizzati in cluster permettendo di avere anche scalabilità usando opportuni metodi per migliorarne i consumi come con la gestione delle frequenze e tensioni a runtime con Dynamic Voltage and Frequency Scaling (DVFS)[7] o power gating e clock gating che disattivano parte della componentistica inutilizzata dal dispositivo[10]. Sfruttare nel modo migliore possibile le prestazioni date da dispositivi edge eterogenei è dunque di notevole importanza e necessita attenzioni apposite. L’obiettivo di questo lavoro è quello di creare un sistema di monitoraggio dei nodi durante l’esecuzione di workload di diverso tipo in modo da ottenerne un dataset utilizzato per addestrare e testare una foresta di alberi decisionali. Un approccio basato su alberi decisionali permette dunque di avere un modello in grado di fare delle previsioni su quale possa essere la strategia migliore da usare per l’esecuzione di uno o più workload minimizzando i consumi del dispositivo; oltretutto un albero decisionale ben addestrato è in grado di fare buone previsioni anche su workload non analizzati permettendo dunque più flessibilità rispetto all’utilizzo di strategie fisse. 1.2 Contributo del lavoro Per permettere la creazione di workload è stata scelta la piattaforma Docker; attraverso questa i workload vengono creati sotto forma di container in modo da garantire un ambiente isolato dal sistema operativo del nodo che deve eseguirli. A differenza di una macchina virtuale un container docker è più leggero e portabile in quanto 1 non ha la necessità di includere un intero sistema operativo al suo interno come nel caso di una macchina virtuale. I container ,rappresentati da un’immagine Docker, vengono poi orchestrati attraverso Kubernetes K3s, una versione leggera di Kubernetes sviluppata per dispositivi con risorse limitate come la KV260, che li avvia e li gestisce in base al loro stato e alla situazione del dispositivo che li esegue. Il contributo di questo lavoro è stato quello di utilizzare le piattaforme Docker e K3s per realizzare un node manager; un programma python in grado di fare il deployment dei workload per poi monitorarli in modo da popolare un dataset usato per addestrare e testare un modello basato su una foresta di alberi decisionali gestito tramite la libreria python Scikit Learn. Quest’ultimo è in grado di fare previsioni sul profilo di frequenza da usare per un workload o un batch, ovvero un gruppo di workload eseguiti contemporaneamente, con parametri specifici. Il node manager fornisce, perciò, le basi per creare in futuro un sistema in grado di applicare la previsione derivante dal modello a tutti i workload che dovranno essere eseguiti dalla Kria KV260 in modo da raggiungere l’obiettivo di ridurne il consumo energetico a runtime. 1.3 Struttura del manoscritto La struttura del manoscritto presenta le idee e le scelte utilizzate in modo da permettere il raggiungimento degli obiettivi. •Il Capitolo 2 descrive l’hardware e i software utilizzati, motivandone la scelta in relazione al contesto applicativo e agli obiettivi del progetto. •Il Capitolo 3 presenta nel dettaglio le fasi di implementazione del sistema, illustrando le soluzioni adottate e le considerazioni fatte. •Il Capitolo 4 riporta i test effettuati, analizza i risultati ottenuti e confronta le misurazioni di consumo energetico. •Il Capitolo 5 riassume gli obiettivi raggiunti e discute possibili sviluppi futuri e miglioramenti applicabili al contesto analizzato. 2 2 Hardware e Software Utilizzati 2.1 AMD Kria KV260 Vision AI Starter Kit La AMD Kria KV260 Vision AI Starter Kit [3] è una piattaforma di sviluppo progettata per applicazioni di visione artificiale e inferenza Artificial Intelligence (AI) edge. Nel progetto Myrtus rappresenta il nodo all’edge dell’infrastruttura ed è in grado di occuparsi dell’esecuzione dei workload richiesti dai livelli superiori. Figura 1: AMD Kria KV260 Vision AI Starter Kit Si basa sul System on Module (SoM) Kria K26 [2], che integra il processore Xilinx Zynq UltraScale+ MPSoC, 4GB Random Access Memory (RAM) DDR4 e ulteriori memorie necessarie al dispositivo. Il SoM è collegato alla scheda che ne fornisce l’interfaccia di Input Output (I-O) permettendogli di installare un sistema operativo attraverso l’uso di una scheda sd ed essere collegato tramite cavo MicroUSB a una Universal Asynchronous Receiver-Transmitter (UART) su un pc o di funzionare in autonomia (con sistemi operativi contenenti una interfaccia grafica) collegandola a un monitor tramite porta HDMI o DisplayPort. La porta Ethernet permette di connetterla alla rete mentre quelle USB consentono la comunicazione con dispositivi di vario tipo. 3 Figura 2: SoM Kria K26 Lo Xilinx Zynq UltraScale+ MPSoC [12] comprende la Application Processing Unit (APU) quad core ARM Cortex-A53, la Real-time Processing Unit (RPU) ARM Cortex-R5F, la Graphics Processing Unit (GPU) MALI 400 MP2 e la logica programmabile (Field-Programmable Gate Array (FPGA)). Queste componenti permettono di usare il dispositivo nei più svariati contesti di elaborazione permettendole di eseguire istruzioni sulla Central Processing Unit (CPU) ma anche utilizzare l’FPGA come acceleratore. Grazie alla sua versatilità, al costo e ai consumi tutto sommato contenuti la KV260 è adottata in molti contesti di ricerca e aziendali. 2.2 Docker L’idea di base è quella di creare e distribuire dei workload da eseguire sui nodi dell’infrastruttura Myrtus riducendo problemi di incompatibilità tra dispositivo e applicazione da eseguire. Docker [5] è una piattaforma che permette di creare degli ambienti isolati chiamati container. Questi contengono al loro interno tutto quello che può essere necessario al workload come installazione di librerie, file aggiuntivi, comandi da eseguire e sistemi operativi customizzati. In questo modo vengono garantite la portabilità e la riproducibilità su infrastrutture differenti permettendo di risparmiare tempo e rendendo il workload stesso più flessibile. 4 Figura 7: Uno degli alberi che compongono la foresta decisionale La figura 7 rappresenta uno degli alberi della foresta decisionale. Questi sono fortemente influenzati dal training set e per questo motivo potrebbero prendere previsioni completamente diverse da alberi addestrati con training set simili. Utilizzare una foresta permette dunque di avere risultati più stabili considerando output di modelli diversi e scegliendo quello più votato (ovvero deciso da più alberi). Figura 8: Dettaglio albero Nella figura 8 viene mostrata una porzione di uno degli alberi decisionali. Nei nodi (3 rettangoli a destra dell’immagine) sono rappresentate le condizioni imposte 11 su un parametro e le risposte possono essere un’affermazione o una negazione; da questa condizione si può passare a un altro nodo o a una foglia (2 rettangoli a sinistra dell’immagine) rappresentante una decisione presa dall’albero corrispondente a class. Samples rappresenta i campioni considerati da un nodo o una foglia, value rappresenta i pesi associati a ognuna delle classi e il più alto è il risultato della decisione presa. Il valore gini rappresenta invece l’impurità del nodo; valori più bassi indicano che le classi hanno valori più sproporzionati e questo si traduce in una scelta più accurata della classe da parte del nodo o della foglia. 12 4 Risultati 4.1 Preparazione per il Deployment Alla base della fase di deployment dei pod ci sono i dockerfile che permettono la creazione dei container attraverso Docker e i file yaml che consentono il deployment vero e proprio con K3s. Questi si trovano rispettivamente nelle cartelle Containers e Yamls del progetto. Codice 1: Esempio di Dockerfile FROM chrimadeddu / ubuntu -22 -04 - kria : latest COPY . /AD_CPU - DPU COPY ./ config / vart . conf / etc /vart . conf WORKDIR / AD_CPU - DPU/ CMD ["sh", "-c", "cp -r benchmark -b4096 / lib / firmware / xilinx && xmutil unloadapp && xmutil loadapp benchmark - b4096 && python3 WLChar_AD_iterative.py"] Il codice 1 mostra uno dei dockerfile utilizzati nel progetto. In questo caso viene importato il sistema operativo Kria Ubuntu 22.04 LTS contenente diverse installazioni effettuate su di esso da un’altra immagine Docker creata in precedenza, copiato il contenuto di diverse cartelle, impostata come directory di lavoro AD_CPU-DPU ed impostati dei comandi da eseguire per il funzionamento del programma python utilizzante FPGA. Codice 2: Creazione e push di una immagine Docker sudo docker login sudo docker build -t chrimadeddu / ad_cpu -dpu - ubuntu : latest . sudo docker push chrimadeddu / ad_cpu -dpu - ubuntu : latest I comandi in 2 consentono di caricare l’immagine nel proprio account docker in modo da utilizzarla successivamente attraverso un file yaml per il deployment. Se l’immagine è pubblica chiunque può utilizzarla per effettuare il deployment di un pod; in questo modo viene reso ancora più semplice e flessibile il procedimento. Codice 3: Esempio di Yaml apiVersion : v1 kind: Pod metadata: name: PLACEHOLDER_NAME labels: app : adcpudpu spec: 13 restartPolicy : Never containers : - name : adcpudpu - container image : chrimadeddu / ad_cpu -dpu - ubuntu securityContext : privileged : true stdin : true tty : true env : - name: PYTHONPATH value : "/ usr /lib / python3 .10/ site - packages " - name: LD_LIBRARY_PATH value : "/ opt/ xilinx / lib :/ usr /lib :/ lib " - name: LD_PRELOAD value : "/ usr /lib / libglog . so " - name: exec_time value : " PLACEHOLDER_EXEC " - name: iterations value : " PLACEHOLDER_ITER " volumeMounts: - name : dri - device mountPath : /dev /dri - name : dfx - socket mountPath : / tmp /dfx - mgrd . socket - name : dpu - drivers mountPath : / lib / firmware / xilinx - name : tmp - shared mountPath : / tmp volumes: - name : dri - device hostPath: path: / dev/dri type: Directory - name : dfx - socket hostPath: path : / tmp /dfx - mgrd . socket type: Socket - name : dpu - drivers hostPath: path : / lib / firmware / xilinx type: Directory - name : tmp - shared hostPath: path: / tmp Il file mostrato in 3 rappresenta un file yaml che permette l’esecuzione dell’immagine creata in 2 nelle fasi successive del progetto. Vengono montati i volumi necessari al funzionamento del workload e specificati i percorsi da seguire. Sono 14 presenti inoltre dei placeholder che permettono di passare dei parametri al codice python da eseguire nel container e infine un placeholder per assegnare un nome al pod da eseguire. 4.2 Workload e parametri utilizzati La fase di test è stata effettuata sulla scheda Kria KV260 su cui è stato scaricato Kria Ubuntu 22.04 Long Term Support (LTS) [11] e sono stati considerati un totale di 5 workload differenti. Constant_High_Cpu eConstant_Low_Cpu simulano un carico costante sulla CPU rispettivamente in multicore (4 nel caso della Kria KV260) e singlecore; i parametri di questi due workload sono idle_time che permette di gestire una fase di idle (o wait) più o meno duratura a inizio workload in modo da simulare un’attesa di risorse di I-O ed exec_time che invece gestisce la durata del tempo di carico. Periodic_High_Cpu ePeriodic_Low_Cpu simulano invece un carico periodico sempre in multicore e singlecore. In questo caso idle_time si riferisce a un periodo di attesa tra due iterazioni mentre exec_time al tempo di ognuna di esse; il parametro iterations, invece, permette di regolare il numero di iterazioni da eseguire. Infine il workload Ad_Cpu_Dpu_Ubuntu riguarda l’analisi di video per il riconoscimento di elementi al loro interno e viene effettuato su CPU ed FPGA in contemporanea. Per questo motivo ci si aspetta valori relativi alla potenza più elevati rispetto ai workload basati solo su CPU. I parametri utilizzati sono iterations ed exec_time e funzionano in modo analogo ai workload Periodici. Sono stati inoltre considerati diversi profili di frequenza in modo da valutare il consumo energetico associato a ognuno di essi. Non è certo, infatti, che utilizzare la minor frequenza disponibile permetta anche il maggior risparmio energetico. Questo perchè in alcuni contesti la durata dell’esecuzione viene estesa tanto da rendere la diminuzione di potenza legata alla minor frequenza della CPU vana comportando addirittura un aumento dei consumi energetici. Exec_Time(sec) Idle_Time(sec) Iterations Constant_Low_Cpu 30-60-120 0-2-5 N/A Constant_High_Cpu 30-60-120 0-2-5 N/A Periodic_Low_Cpu 10-30-60 0-2-5 3-5-10 Periodic_High_Cpu 10-30-60 0-2-5 3-5-10 Ad_Cpu_Dpu_Ubuntu 5-10-30-60 N/A 1-3-5 Tabella 1: Parametri utilizzati nei test. Come mostrato nella tabella 1 sono stati considerati un totale di 9 combinazioni di parametri diverse per i workload costanti, 27 combinazioni per quelli periodici e 15 12 per Ad_Cpu_Dpu. Powersave User1 User2 Performance Frequenza(MHz) 333 444 666 1333 Governor Powersave Userspace Userspace Peformance Tabella 2: Profili utilizzati nei test. Nella tabella 2 vengono mostrati i 4 diversi profili di frequenza supportati dalla Kria KV260. Due di questi sono disponibili sulla KV260 applicando dei governor a ogni core della CPU ovvero Powersave che imposta la frequenza a 333MHz e Peformance che la imposta a 1333MHz. I due profili rimanenti User1 e User2 sono invece stati ottenuti impostando il governor Userspace e settando la frequenza rispettivamente a 444MHz e 666MHz. In totale, dunque, sono stati effettuati 36 test su workload costanti (9 combinazioni di parametri*4 profili), 108 test su workload periodici (27 combinazioni di parametri*4 profili) e 48 su workload CPU-FPGA (12 combinazioni di parametri*4 profili). 4.3 Test sulla Kria KV260 e risultati ottenuti Una volta scelti i workload , i parametri e i profili di esecuzione da considerare può iniziare la fase di test e di creazione del dataset. Il dataset ottenuto è stato suddiviso in due parti: l’80% dedicato all’addestramento della foresta composta da 200 alberi decisionali mentre il restante 20% alla fase di test da cui sono stati estratti e valutati i risultati relativi alle prestazioni del modello creato. 16 Powersave Accuracy [%] User1 Accuracy [%] User2 Accuracy [%] Performance (Default) Accuracy [%] Model Accuracy [%] 0 20 40 60 80 100 Workload CPU Workload CPU-FPGA Figura 9: Accuratezze dei profili e del modello basato su alberi decisionali e differenze tra di loro. La figura 9 mostra uno dei valori più importanti ovvero l’accuratezza del modello; indica la percentuale di situazioni in cui il risultato della previsioni corrisponde con il profilo con minor consumo energetico. Il modello è stato confrontato con alcune strategie fisse e i risultati dimostrano che l’accuracy è superiore. La strategia default (basata sul profilo performance) è quella adottata dal nodo quando non gli vengono imposte direttive sull’esecuzione del workload; in questo caso il confronto con l’accuracy del modello mostra un miglioramento del 56.39% nel caso di soli workload su CPU. Nel caso invece di workload misti CPU e CPU-FPGA il miglioramento scende al 43,14% rimanendo comunque consistente. Rispetto alla strategia User1, la migliore tra quelle fisse, la differenza diventa di 18.89% nel primo caso e 24.09% nel secondo. Va ribadito, però, che la differenza principale con le strategie fisse è relativa a workload sconosciuti; un modello ben addestrato, infatti, è in grado di prendere buone decisioni anche in casistiche non affrontate in precedenza e inoltre è in continuo possibile miglioramento grazie all’addestramento che può ricavare da essi. Per questo motivo un modello addestrato diventa maggiormente vantaggioso a lungo termine. 17 VS Powersave [%] VS User1 [%] VS User2 [%] VS Performance [%] −2 0 2 4 6 8 10 Workload CPU Workload CPU-FPGA Figura 10: Risparmio energetico con workload CPU e workload CPU-FPGA rispetto ai profili fissi e al caso migliore. La figura 10 mostra come dal punto di vista energetico il modello addestrato fornisca un guadagno di 6.51% rispetto alla strategia baseline con workload su CPU e di 4.89% nel caso CPU e CPU-FPGA. Questi valori scendono rispettivamente a 0.48% e 1.35% se paragonato alla strategia User1. L’impatto energetico è dunque più apprezzabile in casistiche di workload molto energivori o necessità di risparmio energetico massimo (ad esempio se il nodo è collegato a una batteria di alimentazione) in cui anche valori percentili bassi possono fare la differenza. Non si escludono, inoltre, miglioramenti sostanziali dati da ulteriore addestramento del modello anche in relazione a una maggiore accuracy. 18 5 Conclusione Il progetto realizzato ha dunque permesso di avere un sistema funzionante su Kria KV260 in grado di eseguire e monitorare workload in modo flessibile permettendo di aggiungerne ulteriori, modificare i presenti e fare ulteriori analisi con parametri differenti per poi realizzare un modello per la presa di decisioni a runtime. I risultati sono una base discreta per fornire una gestione energetica per il contesto applicativo del progetto Mytrus. Tra i possibili sviluppi e approfondimenti sono di particolare interesse la creazione di un dataset più esaustivo comprendente ulteriori categorie di workload, una funzionalità di gestione a runtime della frequenza nei momenti di idle del sistema per diminuire l’energia utilizzata e un sistema di gestione del power gating in grado di disattivare uno o più core inutilizzati in modo da risparmiare ulteriore energia. Queste soluzioni permetterebbero migliorie ancora più nette sul fronte energetico rispetto a una esecuzione standard da parte del nodo. 19 Lista degli acronimi AI Artificial Intelligence. 3 APU Application Processing Unit. 4 CPU Central Processing Unit. 4, 8, 9, 15, 17, 18 DVFS Dynamic Voltage and Frequency Scaling. 1 FPGA Field-Programmable Gate Array. 4, 15, 17, 18 GPU Graphics Processing Unit. 4 I-O Input Output. 3, 15 K3s Lightweight Kubernetes. 5, 9, 13 LTS Long Term Support. 15 RAM Random Access Memory. 3 RPU Real-time Processing Unit. 4 SoM System on Module. 3 UART Universal Asynchronous Receiver-Transmitter. 3 20