# Piattaforme e Software per la rete - lezione 8
#### William Fornaciari
###### 14 April 2016
## Run Time Resource Management
Necessario per gestire come le applicazioni occupano le risorse
di elaborazione, posso avere distinzioni tra le applicazioni,
ad esempio alcune possono essere critiche e non interrompibili
mentre altre possono essere ritardate se necessario.

Gli obiettivi per RTRM sono:
- __scalabilità__: il sistema deve funzionare con pochi o molti core
- __retargetabilità__: il sistema può funzionare su architetture eterogenee.
L'obiettivo è una __system-wide optimization__ che non si limita solo a
ricercare delle prestazioni elevate.

Un approccio per dominare e ridurre la complessità del problema 
è agire in modo *gerarchico*, ad esempio posso avere politiche a livello
di nodi, o di board...

Quando si lavora su processori sotto i 22nm, trovo il problema della
__process variability__ cioè un esemplare di un chip funziona
diversamente da un altro (es: frequenza massima di funzionamento)
o varia anche da un core all'altro.
Per questo al momento del mapping tra cpu virtuali e cpu fisiche
bisogna far attenzione ad alcuni dettagli (non sempre calcolabili)
Ad esempio se il processo precedente ha scaldato la cpu, il processo
attuale non potrà sfruttare a pieno il carico termico (problema hot-spot)

Quindi serve fare __accounting__ delle risorse e __monitoring__

### Working Modes
È l'unione tra la configurazione della piattaforma di calcolo
e la configurazione dell'applicazione, es:20fps su un quad-core a 800mHz
Devono esserci dei punti di controllo in modo da cambiare alcuni parametri.
E devono esserci dei punti di osservabilità per valutare i risultati.

## Barbecue RTRM

*Barbecue* è l'RTRM più avanzato presente sul mercato
Barbecue effettua il mapping tra le risorse virtuali richieste dalle applicazioni
sulle risorse fisiche attualmente disponibili.

Nell'aspetto fisico della cpu, data una certa frequenza, ho una tensione minima
per mantenerlo a quella frequenza, mentre ad una certa tensione la cpu può raggiungere
una determinata frequenza dipendente da quest'ultima, si cerca quindi di sfruttare
il punto più vantaggioso tra frequenza e tensione.

Ho molti cicli di controllo, suddivisi su diversi livelli:
- livello applicazione: ottimizzo utilizzo risorse
- livello sistema: partiziono le risorse
- livello firmware
Quindi a grandi linee ho un sistema __gerarchico distribuito__.
Barbecue lavora a livello __system-wide__

Durante lo sviluppo di barbecue, è stato risolto il problema multiobiettivo
del modello teorico di allocazione (simile a knapsack o tsp) ed è stata creata
un'euristica per ottenere risultati simili al modello teorico.
L'overhead del sistema è stato limitato al 10%