lesson_08.md 2.7 KB

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%