Riassunto analitico
Il sottosistema di memoria condivisa degli odierni sistemi multiprocessore su chip (MPSoC) è una nota fonte di interferenza. Quando si accede alla memoria condivisa, i core altrimenti isolati potrebbero interferire tra loro, causando latenze difficili da prevedere e altamente variabili. Ciò a sua volta porta a "tempi di esecuzione nel caso peggiore" complessi e pessimistici (WCETs). A questo proposito, la regolazione della larghezza di banda della memoria basata sui contatori delle prestazioni sistema (e.g., Memguard [7]) è una tecnica ben studiata per mitigare le interferenze e ripristinare la predicibilità. MemGuard raggiunge questo obiettivo limitando gli accessi alla memoria in base al core in esame. In questo lavoro, abbiamo sviluppato MemGuard-PAIRED, un'implementazione di MemGuard nel Sistema Operativo Real Time NuttX [3], su una versione emulata del SoC Al Saqr [5]. Questo sistema è basato sulla CPU CVA6 (ISA RISC-V) [4], e, essendo ancora in sviluppo, è attualmente emulato su una FPGA VCU118. MemPAR sfoggia le seguenti caratteristiche. In primo luogo, regola dinamicamente i suoi parametri, in funzione del suo overhead di esecuzione: ovvero, MemPAR cerca di mantenere il suo periodo di attivazione uguale al valore più basso possibile (granularità temporale più fine) che non provochi un overhead medio rilevante. In secondo luogo, MemPAR affronta l'assenza di overflow interrupt nell'attuale standard RISC-V. Per aggirare questa assenza, MemPAR esegue periodicamente il polling dei contatori delle prestazioni per core, per rilevare se gli accessi alla memoria devono essere limitati per alcuni core. In particolare, MemPAR esegue questo controllo all'interno del generico dispatcher degli interrupt. Ciò garantisce che il controllo venga eseguito ad ogni attivazione di un interrupt e quindi venga eseguito sempre più frequentemente all'aumentare del carico del sistema. Cioè, maggiore è il carico del sistema (e quindi è probabile che sia più critica la regolazione della larghezza di banda) e più frequentemente MemPAR interviene per limitare i core quando necessario. Inoltre, nel caso in cui un controllo venga eseguito in ritardo, e di conseguenza un core consuma più larghezza di banda di quella assegnata, un meccanismo di penalità fa sì che il core restituisca la larghezza di banda extra che ha consumato. Infine, la limitazione non viene implementata a livello di core, ma a livello di task. In particolare, a differenza delle precedenti implementazioni di MemGuard, MemPAR non limita un core forzando il passaggio ad un idle task (sprecando così l'intero core durante la limitazione), ma semplicemente sospendendo il task currente. Questo non solo costa circa la metà del passaggio ad un idle task, ma lascia anche il core disponibile per l'esecuzione di altro lavoro.
|
Abstract
The shared memory subsystem of today’s multiprocessor systems on a chip (MPSoC) is a well-known source of interference. When accessing shared memory,
otherwise isolated cores may interfere with each other, resulting in hard-to-predict and highly variable latencies. This in turns leads to complex and pessimistic worst
case execution times (WCETs). In this respect, performance-counter-based memory bandwidth regulation (e.g., MemGuard [7]) is a well studied technique for mitigating interference and restoring predictability.
MemGuard achieves this goal by controlling throttling memory accesses on a per-core basis.
In this work, we developed MemPAR, an implementation of MemGuard in the NuttX RTOS [3], on top of an emulated version of the Al Saqr SoC [5]. This system
is based on the CVA6 CPU (RISC-V ISA) [4], and, being still in development, is currently emulated on a VCU118 FPGA.
MemPAR exhibits the following features. First, it dynamically auto-tunes its parameters, as a function of its own execution overhead: namely, MemPAR tries to
keep its activation period equal to the lowest possible value (finest possible time granularity) that does not cause a relevant average overhead. Secondly, MemPAR
addresses the absence of overflow interrupts in current RISC-V standard. To work around this absence, MemPAR polls per-core performance counters periodically, to
detect whether memory accesses from some core must be throttled. Specifically, MemPAR performs this check within the generic interrupt dispatcher. This guarantees that
the check is performed on every interrupt activation and is therefore executed more and more frequently as the system load grows. That is, the higher
the system load (and therefore the more critical bandwidth regulation is likely to be) and the more frequently MemPAR intervenes to throttle cores when needed.
Furthermore, in case a check happens to be performed late, and consequently a core happens to consume more bandwidth than allotted, a penalty mechanism makes
the core return the extra bandwidth it has consumed. Finally, throttling is not implemented at core, but at task level. In particular, differently from previous MemGuard
implementations, MemPAR does not throttle a core by forcing a switch to an idle task on that core (thereby wasting the whole core during the throttling), but by just
suspending the current task. This not only costs about half a switch to an idle task, but also leaves the core available for executing other work.
|