Characterization of virtualization performance in embedded systems: a case of study

The growing demand for computing power and advanced functionality has led to the integration of components with different criticality levels on the same platform, giving rise to Mixed-Critical Systems in which applications with strict timing constraints coexist alongside non-critical components. In critical systems, meeting timing deadlines is an essential requirement for certification; for this rea- son, our goal is to quantify overhead and isolation on the Raspberry Pi 5, chosen as a cost-effective platform for mixed-criticality embedded workloads, in order to evaluate the Xen hypervisor, which is commonly used in these scenarios. This work addresses the following four questions: (I) How much overhead does Xen introduce in terms of computational performance? (II) How much overhead does Xen intro- duce in terms of latency? (III) To what extent is Xen able to maintain temporal isolation among different guests? (IV) To what extent can cache coloring limit the impact of interference caused by memory usage of the guests? With respect to question (I), we ran a set of benchmarks from the NuttX project on Raspberry Pi 5: the results do not show a degradation in the execution of programs that perform memory operations; A clear reduction in computational power is observed when the operating system uses the system timer, with an overhead of 33% in the case of a test writing to memory. The tests also show a degradation in cache-management performance, due to a different cache configuration between Xen and NuttX. To answer question (II), we used two tests: a bare-metal application that measures the time between the generation of the timer interrupt and its reception in the guest, and Cyclictest (Linux Foundation). The results show a 2 μs delay in in- terrupt propagation; Cyclictest shows a 10% gain in the virtualized environment. Regarding question (III), we repeated the tests from question (I) in the presence of multiple interfering guests executing memcpy with varying sizes: performance consistently degrades as the copied size and the number of guests increase, with a slowdown of up to 61% in memory operations. To answer question (IV), we reran the same tests with cache coloring enabled: we observe a 24% improvement when interfering guests copy blocks on the order of the L3 cache size and a 120% degradation with blocks on the order of the L2 cache size. This shows that cache management can mitigate (or sometimes exacerbate) system interference. Cache coloring reduces the effectively usable cache space to mitigate interference; this constraint also propagates to the L1 and L2 caches, degrading performance in cer- tain scenarios.

La crescente domanda di potenza di calcolo e di funzionalità avanzate ha portato all’integrazione, sulla stessa piattaforma, di componenti con diversi livelli di criticità, dando origine ai Mixed-Critical Systems, nei quali applicazioni con vincoli temporali stringenti convivono con componenti non critici. Nei sistemi critici il rispetto delle scadenze temporali è un requisito essenziale per la certificazione; per questo motivo, il nostro obiettivo è quantificare overhead e isolamento su Raspberry Pi 5, scelta come piattaforma economica per carichi di lavoro embedded a criticità mista, al fine di valutare l’hypervisor Xen, comunemente utilizzato in questi scenari. Questo lavoro affronta le seguenti quattro domande: (I) Qual è l’overhead introdotto da Xen in termini di prestazioni computazionali? (II) Qual è l’overhead introdotto da Xen in termini di latenza? (III) In che misura Xen è in grado di mantenere l’isolamento temporale tra diversi guest? (IV) In che misura il cache coloring può limitare l’impatto delle interferenze causate dall’uso della memoria da parte dei guest? Per quanto riguarda la domanda (I), abbiamo eseguito un insieme di benchmark del progetto NuttX su Raspberry Pi 5: i risultati non mostrano degradazioni nell’esecuzione di programmi che effettuano operazioni di memoria; si osserva invece una chiara riduzione della potenza computazionale quando il sistema operativo utilizza il system timer, con un overhead del 33% nel caso di un test di scrittura in memoria. I test evidenziano inoltre un peggioramento delle prestazioni nella gestione della cache, dovuto a una diversa configurazione della cache tra Xen e NuttX. Per rispondere alla domanda (II), abbiamo utilizzato due test: un’applicazione bare-metal che misura il tempo tra la generazione dell’interrupt del timer e la sua ricezione nel guest, e Cyclictest (Linux Foundation). I risultati mostrano un ritardo di 2 μs nella propagazione dell’interrupt; cyclictest mostra un guadagno del 10% nell’ambiente virtualizzato. Per quanto riguarda la domanda (III), abbiamo ripetuto i test della domanda (I) in presenza di più guest interferenti che eseguono memcpy con dimensioni variabili: le prestazioni degradano sistematicamente all’aumentare della dimensione copiata e del numero di guest, con un rallentamento fino al 61% nelle operazioni di memoria. Per rispondere alla domanda (IV), abbiamo rieseguito gli stessi test con il cache coloring abilitato: osserviamo un miglioramento del 24% quando i guest interferenti copiano blocchi dell’ordine della dimensione della cache L3 e un peggioramento del 120% con blocchi dell’ordine della cache L2. Ciò mostra che la gestione della cache può mitigare (o talvolta amplificare) le interferenze di sistema. Il cache coloring riduce lo spazio di cache effettivamente utilizzabile per attenuare le interferenze; questo vincolo si propaga anche alle cache L1 e L2, degradando le prestazioni in alcuni scenari.