Elaborato Gargiulo Federico n460001149

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Sistemi Real Time
Algoritmi per lo scheduling di task real-time
su piattaforme multicore
Anno Accademico 2014/2015
Candidato:
Federico Gargiulo
matr. N46001149
Ai ragazzi della Capricorni, ma
soprattutto a tutti gli arrivisti
incontrati
Indice
Indice .................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: Panoramica ........................................................................................................................ 6
1.1 Terminologia .............................................................................................................................. 7
1.2 Problematiche delle piattaforme Multicore.............................................................................. 10
Capitolo 2: La prelazione nelle piattaforme multicore ...................................................................... 12
2.1 System Model, Assunzioni e Notazioni ................................................................................... 12
2.2 Policy e algoritmo di MPN ...................................................................................................... 12
2.3 Analisi di schedulabilità degli algoritmi MPN-* ..................................................................... 14
Capitolo 3: .......................................................................................................................................... 16
3.1 Algoritmo di scheduling PAS-SRTMS .................................................................................... 17
Capitolo 4: Bilanciamento del carico computazionale ...................................................................... 20
4.1 System Model, Assunzioni e Notazioni ................................................................................... 20
4.2 Scheduler Real-Time di Partizionamento ................................................................................ 21
4.3 Load Balancing Based Task Partitioning (LBTP) ................................................................... 22
4.4 Schedulabilità in LBTP ............................................................................................................ 23
Capitolo 5: Applicazioni Mixed-Criticality ....................................................................................... 25
5.1 Time-Triggered and Synchronisation-based strategy (TTS) ................................................... 26
5.2 Policy ....................................................................................................................................... 27
5.3 Schedulabilità e certificazione in TTS ..................................................................................... 28
Conclusioni ........................................................................................................................................ 30
Bibliografia ........................................................................................................................................ 32
Introduzione
I sistemi real-time sono quei sistemi il cui corretto funzionamento dipende anche dal tempo
di risposta.
Non basta, quindi, che la logica operazionale sia esatta ma è necessario anche che le
operazioni vengano compiute nel rispetto di vincoli temporali ben definiti.
Molteplici sono i settori di impiego: nel controllo di produzioni industriali, nell'ingegneria
biomedica, nell'aviazione, nelle telecomunicazioni, nella sorveglianza ambientale etc.
Il grado di affidabilità da garantire è spesso tanto elevato da far obbligo al progettista di
ricorrere a tecniche di programmazione ad hoc allo scopo di avere un controllo maggiore
del sistema. Vengono spesso usate tecniche di progetto più accurate, metodologie di analisi
statica del codice sorgente, e meccanismi per la gestione della variabile tempo. A questo va
aggiunto che la progettazione deve essere tale da garantire il perfetto funzionamento anche
a fronte della peggiore combinazione possibile di eventi.
Ai fini progettuali, un sistema di tipo real-time dovrà essere per così dire prevedibile. Nulla
dovrà essere lasciato al caso e i tempi di reazione di ciascun componente dovranno essere
sempre predicibili.
Per semplicità di progettazione vengono spesso adottati calcolatori meno complessi, in
genere mono core, e sistemi operativi minimali.
Oggi, però, la crescente richiesta di maggiori performance, in termini temporali e di calcolo,
assieme all'esplosione del mercato dei processori multicore hanno attirato l'attenzione della
comunità scientifica sulla ricerca di nuove tecniche per lo scheduling di task real-time.
Oltretutto bisogna ricordare che il parallel computing ormai è ovunque. Le architetture
multicore stanno dominando il mercato e trovano largo impiego in sistemi che vanno dagli
embedded, ai personal computer fino ai supercalcolatori ad alte performance.
Le tecnologie hardware hanno però mantenuto un passo diverso da quelle software. Le CPU
multicore necessitano di tecniche di programmazione ovviamente diverse da quelle
monocore, ma soprattutto il calcolo in parallelo e la gestione esplicita della memoria
aggiungono complessità alla progettazione dei sistemi. Una complessità che si ripercuote
4
per forza di cose anche nei sistemi real-time, dove certamente non è possibile lasciare nulla
al caso.
Un po' sospinti dai mutamenti del mercato hardware e un po' costretti dalle esigenze di
applicazione, l'attenzione dei team di ricerca sui sistemi real-time si è spostata per gran parte
anche sulle piattaforme multicore.
5
Capitolo 1: Panoramica
La bontà di un sistema di calcolo è data da una molteplicità di fattori che vanno da
caratteristiche fisiche, ai meccanismi di nucleo, fino agli applicativi. Ovviamente i
meccanismi di gestione dell'hardware devono essere accompagnati da modelli matematici
precisi che permettono di avere una stima dei comportamenti del sistema a tutti i possibili
stimoli in ingresso.
Questo pieno controllo può essere possibile solo attraverso un'adeguata chiaroveggenza da
parte degli algoritmi software di controllo. Questa prevedibilità diventa così il cardine
dell'intero apparato. Affinché un sistema possa essere adottato in un contesto
particolarmente delicato, nelle procedure ciascun parametro temporale dovrà essere noto a
priori e perché si possano anticipare i comportamenti, è indispensabile che essi siano
descritti da un modello matematico esatto che tenga conto anche dei peggiori scenari di
esecuzione. Arriviamo dunque a capire la motivazione che spinge i progettisti ad adottare
configurazioni fisiche semplici (e spesso anche non recenti) nelle quali vengono disabilitati
dispositivi e meccanismi che introducono aleatorietà nei comportamenti, come Cache,
DMA, Interrupt etc.
E' ovvio che non tutti i casi applicativi richiedano garanzie troppo forti, anzi può capitare
che i tempi di risposta siano importanti ma non tanto da inficiare la sicurezza di chi ne fa
uso. Garantire una maggiore affidabilità comporta maggiori costi di sviluppo e produzione,
dei costi che alla fine saranno a carico del cliente, motivo per cui non sempre è necessario
adottare strategie eccessivamente drastiche per il design del sistema.
Altre volte invece su uno stesso apparato può essere utile integrare sistemi di diverso grado
di affidabilità, ad esempio basti pensare che può tornare utile aggiungere anche
un'interfaccia utente per il controllo di alcuni parametri o per avere semplicemente la
possibilità di leggere dei report dal sistema. E' facile pensare che ad una interfaccia utente
non sarà riservata la stessa attenzione rivolta alla parte che si interessa del controllo vero e
proprio, quindi i vincoli temporali non assumeranno la medesima importanza.
Dal momento che il mercato lascia spazio a tipologie di sistemi real-time i cui vincoli sono
6
meno stringenti, la comunità scientifica sta partorendo nuovi algoritmi per gestire processi
Real-Time anche su piattaforme multicore, la cui adozione solo fino a qualche anno fa
poteva sembrare utopica. Dei primi modelli matematici per il dimensionamento software
sono stati introdotti ma non soddisfano ancora appieno tutti i gradi di affidabilità (o di
calcolo) richiesti dal mercato. Oltretutto l'introduzione di CPU multicore ha aperto molte
strade ancora da percorrere e nuove problematiche, alle quali un prima soluzione si è iniziata
a dare. In questo lavoro ci soffermeremo sugli ultimi sviluppi in questo campo e faremo una
fotografia dello state-of-art, trattando dapprima la terminologia tecnica usata,
successivamente introducendo le problematiche affrontate e in fine entrando nel dettaglio
di alcune soluzioni proposte.
Passiamo quindi ad introdurre alcuni concetti chiave.
1.1 Terminologia

Task. Con la parola Task intendiamo una sequenza di istruzioni che viene eseguita
dal processore in modo continuativo fino al suo completamento. Spesso viene
tradotto in Italiano con la parola Processo.

Scheduler. Col termine scheduler si intende l'algoritmo che, presi in ingresso un
insieme di Task, definisce un ordine gerarchico per l'accesso alle risorse (siano esse
fisiche o virtuali) allo scopo di conseguire, in modo efficiente, un coordinamento tra
i processi in esecuzione.
Questo algoritmo può essere ottimizzato per scopi diversi. Ad esempio un sistema
operativo per un utente client sarà caratterizzato da tempi di attesa per l'utente
nettamente inferiori rispetto ad un sistema operativo server. Questi tempi di attesa
sono una diretta conseguenza delle politiche di scheduling.

Vincoli su risorse. Alcune risorse, siano esse istruzioni, dati o quant'altro, possono
essere mutuamente esclusive, questo comporta che un task che voglia farvi accesso
deve sottostare ad una policy di scheduling che garantisca un coordinamento tale da
7
impedire più accessi in contemporanea e mantenere la consistenza delle strutture dati
interne.
Queste tipologie di risorse prendono il nome di risorse mutuamente esclusive e le
relative porzioni di codice, il cui accesso è sempre mutuamente esclusivo, prendono
il nome di sezioni critiche.
Rispettare un vincolo su risorsa significa quindi
sincronizzare i processi che tentano un accesso simultaneo, al fine di consentire un
uso della struttura dati condivisa, mutuamente esclusivo.

Stati di un processo. Si considerino due processi J 1 e J 2 , che utilizzano una
struttura dati condivisa. Supponiamo che i due processi possano subire preemption,
ossia una sospensione dovuta a una prelazione di task più importanti, e supponiamo
che J 1 sia più importante di J 2 .
In queste condizioni, se il task J 2 viene attivato per primo, e J 1 arriva quando J 2
è all'interno della sezione critica, si ha la situazione riportata in figura 1.1
Nell'istante t 2 , il processo J 1 tenta di entrare nella sezione critica occupata dal
processo J 2 . Il sistema blocca l'accesso di J 1 per garantire la mutua esclusione
sulla risorsa e restituisce il processore a J 2 . J 1 può riprendere l'esecuzione solo
quando, all'istante t 2 , J 2 libera la sezione critica.
I processi in attesa di risorse condivise occupate si dicono bloccati sulla risorsa, e
vengono accodati in una coda associata al meccanismo di protezione della risorsa. Il
8
sistema operativo deve prevedere uno stato apposito per la sospensione dei processi
bloccati su risorse, che chiameremo stato dei processi bloccati (BLOCKED).
Un processo entra nello stato BLOCKED ogni volta che tenta l'accesso ad una risorsa
occupata e ne esce quando la risorsa viene liberata.

Scheduler Real-Time. Uno scheduler viene definito di tipo Real-Time quando tiene
conto di vincoli temporali dettati dal contesto di applicazione.
Una schedulazione in questo caso si dice fattibile se esiste un assegnamento dei task
al processore tale che tutti i task siano completati rispettando un insieme di vincoli
prefissati.
Un insieme di task si dice schedulabile se per esso esiste una schedulazione fattibile.
Infine si definisce preemptive se il processo in esecuzione può essere sospeso in
qualsiasi istante, allo scopo di assegnare il processore ad un altro task secondo una
strategia prefissata. In questo caso è possibile che un processo sia eseguito in
intervalli di tempo disgiunti (ovvero non consecutivi).

Deadline. La parola Deadline (scadenza, in italiano) viene usata per definire un
particolare vincolo temporale attribuito ad un task. Essa rappresenta il tempo
9
massimo entro cui un processo deve terminare la propria esecuzione al fine di non
provocare malfunzionamenti nel sistema.

Classificazione. Le conseguenze dettate da un missed deadline sono il discrimine
con cui possiamo distinguere processi Hard Real-Time da processi Soft Real-Time.
Essi hanno un grado di importanza nettamente differente, poiché nei primi una
violazione temporale può avere conseguenze di elevata rilevanza (come disastri
ferroviari, aerei, fallimenti di apparecchiature biomediche etc.) mentre nei secondi
al
più
si
possono
avere
degradi
prestazionali.
Un sistema operativo dotato di uno scheduler in grado di processare task Hard realtime viene definito di tipo hard, analogamente uno dotato di scheduler in grado di
processare solo task Soft real-Time viene definito di tipo soft. Esiste un connubio
rappresentato dai sistemi Mixed-Criticality i quali si occupano di schedulare un
insieme di task con differente livello di importanza.

Multicore. Introduciamo adesso il concetto di CPU multicore. Per aumentare le
performance dei processori, negli anni si è cercato di incrementare la frequenza di
clock e conseguentemente il numero di istruzioni eseguite in un quanto di tempo.
Questo approccio è stato possibile fintanto che la miniaturizzazione dei transistori
e il calore dissipato dal dispositivo non sono diventati un ostacolo troppo difficile da
superare. Integrare in una CPU più nuclei di calcolo ha permesso di valicare questi
impedimenti,
incrementando
l'efficienza
di
calcolo
e
riducendo
contemporaneamente anche il costo energetico. Le CPU composte da più processori
fisici, i nuclei di calcolo, prendono il nome di multicore.
1.2 Problematiche delle piattaforme Multicore
Come sempre, non tutto è oro quello che luccica. Le piattaforme basate su componenti di
calcolo multicore hanno portato con sé una sfilza di problemi ai quali ancora oggi si sta
cercando di ovviare. La crescente complessità delle componenti hardware si traduce in una
più difficoltosa gestione delle risorse fisiche e virtuali. Nei Sistemi Real-Time queste
10
problematiche di gestione si accentuano al punto da diventare probabilmente le tematiche
portanti della ricerca scientifica in questo campo. Innanzitutto i task attivi in un istante
qualsiasi possono essere molteplici, quindi l'accesso alle risorse condivise deve essere
regolato tenendo presente anche le richieste provenienti da più processi, a seconda della
policy adottata vi sarà un vincitore e gli altri processi che hanno partecipato alla contesa si
troveranno a cambiare stato, passando in quello di blocked. Non capita raramente che si
abbiano contemporaneamente core liberi e molti processi in stato di blocked, causando
quindi un decadimento dell'efficienza d'uso della CPU.
A queste si aggiungono problematiche di tipo energetico, in quanto spesso le CPU sono
capaci di adattarsi al contesto di lavoro, aumentando i livelli prestazionali. Un cattivo
bilanciamento del carico computazionale aumenta la spesa energetica, uno scenario che può
diventare critico in sistemi embedded che non sono collegati alla rete elettrica (ad es in
dispositivi biomedici come i pacemaker) .
Ulteriori problemi per questo tipo di piattaforme sorgono per l'uso della memoria Cache,
una memoria ad alte prestazioni di piccola quantità che viene spesso integrata nelle CPU.
Un task che richiede un dato, dovrà prima cercarlo in memoria cache e se la ricerca non
dovesse andare a buon fine, passare in memoria centrale, inoltre alcuni livelli di Cache, nei
processori commerciali, sono spesso in comune tra i core causando un numero
considerevole di competizioni per l'accesso. Entrambe possono essere delle operazioni non
predicibili temporalmente e quindi fonti di non determinismo. A queste problematiche se ne
aggiungono molte altre, come la gestione di bus comuni, l'uso del DMA, etc. , ma che
esulano dal compito di questo elaborato.
11
Capitolo 2: La prelazione nelle piattaforme multicore
Negli ultimi anni, la maggior parte delle teorie di scheduling real-time per piattaforme
multicore si è focalizzata su scheduling full-preemptive. Può capitare, però, che a seconda
della natura dei task, sia necessario per alcuni di essi (anche solo una piccola parte di un
set), che durante la loro esecuzione non vengano prelazionati da altri. Nei sistemi non realtime ovviamente sono state già adottate diverse soluzione ma non negli RTOS. Vale a dire
che finora non vi è stata possibilità di una via di mezzo tra politiche fully-preemptive o nonpreemtive.
Solo recentemente si è introdotto l' MPN (mixed preemptive/non-preemptive) policy, grazie
al quale ciascun task può essere di tipo preemptive o non-preemptive. Prima di introdurre
l'algoritmo vero e proprio, trattiamo brevemente le assunzioni e le notazioni da fare per il
System Model dopodichè passiamo a valutare l'affidabilità di questa politica osservando il
test di analisi correlato.
2.1 System Model, Assunzioni e Notazioni
Ciascun task τi ∈Φ (insieme di tutto il set di task) è rappresentato da (T i ,C i , Di ) , dove
Ti
è il tempo minimo tra due invocazioni successive, C i è il worst-case execution time, e
Di è la relativa deadline.
Per ciascun τi ∈Τ , introduciamo un parametro addizionale Y i che indica la proprietà di
prelazione del rispettivo task.
2.2 Policy e algoritmo di MPN
Passiamo ora a descrivere la politica di preemption di MPN. La decisione viene presa
innanzitutto sulla base di un parametro Y i del task τi . Cioè, se Y i =1 (Y i =0) , un job di
τi
può (o non può) essere prelazionato dagli altri job a priorità maggiore durante la sua
esecuzione. Chiameremo questa politica con l'appellativo di mixed preemptive/non12
preemptive (MPN) policy.
Da adesso useremo mpn-* per indicare l'algoritmo di scheduling che adotta MPN e * per
indicare genericamente la sua politica di preemption o non-preemption.
L'esempio riportato di seguito fornisce una descrizione di un mpn-* algoritmo di scheduling
una piattaforma multicore. Dal momento che ci possono essere alcuni job non-preemptive
sotto mpn-*, il Job Release avanza agli step 4 e 5 esentando gli job non-preemptive
attualmente in esecuzione dall'essere prelazionati da job appena invocati. Questa è la
principale differenza tra uno scheduler fp-* (algoritmi con fully-preemptive policy) a un
mpn-* . L'overhead implementato da mpn-* non è significativo in quanto la maggior parte
degli steps dell'algoritmo sono anche richiesti dall'algoritmo fp-* . Cioè mpn-* in aggiunta
richiede la verifica della condizione di Y k =1 nello step 4 e la seconda condizione di « if »
nello step 5, e la memorizzazione di un bit addizionale (Y k ) per il task. D'altronde, mentre
tutti i task sotto fp-* possono essere prelazionati, soltanto alcuni task sotto mpn-* possono
incorrere in preemption e migration.
Quando adottiamo EDF come prioritization policy, mpn-EDF determina le priorità dei job
a seconda delle rispettive deadline. Perciò la deadline dei job è usata per comparare le
13
priorità dei job nell'algoritmo di Job Realese agli step 4 e 5 e Job Completion al primo step
dell'algoritmo. D'altronde, mpn-FP determina le priorità su quelle fissate dai task, e quindi,
la task priority è usata per le comparazioni. Si noti che la descrizione dell'algoritmo, per ora,
soddisfa le politiche di priorità nelle quali la priorità di ciascun job non cambia nel tempo
(EDF, FP etc.), tuttavia può essere esteso anche a politiche a priorità dinamica. Quindi la
politica di MPN e l'algoritmo mpn-* sono delle generalizzazioni di non-preemptive e
preemptive policies, e di np-* e fp-* come dichiarato nel seguente lemma.
Lemma 1 : La politica MPN assume le politiche preemptive e non-preemptive, mentre gli
algoritmi di scheduling mpn-EDF e mpn-FP assumono np-EDF e fp-EDF, e np-FP e fp-FP,
rispettivamente.
La prova è abbasta semplice. La non-preemptive (o preemptive) policy è equivalente alla
MPN policy con Y i =0(Y i=1) per tutti i task τ∈ϕ e np-EDF (o fp-EDF) è equivalente a
mpn-EDF con Y i =0(Y i=1) per tutti i task τ∈ϕ . Lo stesso vale per mpn-FP con np-FP e
fp-FP.
2.3 Analisi di schedulabilità degli algoritmi MPN-*
14
L'analisi di schedulabilità per gli algoritmi MPN-* è data dalle due relazioni del teorema
che segue.
Teorema. Quando un insieme di task Φ è schedulato da un algoritmo di schedulazione
mpn-*, un upper-bound del tempo di risposta di un task preemptive τ k | Y k =1∈Φ è
⩽R xk soddisfi la seguente espressione, partendo da R0k =C k
Rk =Rkx tale che R(x+1)
k
𝑅𝑘𝑥+1 ⃪ 𝐶𝑘 + ⌊
1
𝑚
∑
∗
(𝐹𝑘𝑥 ), 𝐹𝑘𝑥 )⌋
min(𝐼𝑘⃪𝑖
𝜏𝑖 𝜖𝜙−{𝜏𝑖 }
E un upper-bound del tempo di risposta di un task non-preemptive 𝜏𝑘 | 𝑌𝑘 = 0 ∈ Ф è 𝑅𝑘 =
𝐹𝑘𝑥 + 𝐶𝑘 − 1tale che 𝐹𝑘𝑥+1 ≤ 𝐹𝑘𝑥 soddisfi la seguente espressione, partendo da 𝐹𝑘0 = 1
𝐹𝑘𝑥+1 ⃪1 + ⌊
1
𝑚
∑
∗
(𝐹𝑘𝑥 ), 𝐹𝑘𝑥 )⌋
min(𝐼𝑘←𝑖
𝜏𝑖 ∈Ф−{𝜏𝑘 }
Quindi se 𝑅𝑘 ≤ 𝐷𝑘 è soddisfatta per tutti i task 𝜏𝑘 ∈ Ф, 𝑎𝑙𝑙𝑜𝑟𝑎 Ф è schedulabile secondo
l’algoritmo.
15
Capitolo 3:
Il consumo energetico di un Sistema Real-Time può essere un fattore di particolare
importanza in quei sistemi dotati di alimentazione propria e quindi non collegati ad una
fonte energetica continua. L’impiego di dispositivi dotati di accumulatori di corrente è in
forte crescita, basti pensare che in ambito biomedico numerose protesi elettroniche
funzionano per mezzo di batterie, oppure un caso analogo può essere quello di
apparecchiature professionali portatili.
L’assorbimento energetico della CPU è spesso tra i fattori cruciali di consumo all’interno di
un calcolatore. La cosa si accentua nel momento in cui la complessità e le performance
richieste aumentano considerevolmente, la potenza dissipata da un processore generalmente
cresce in modo proporzionale alle sue performance. Spesso i processori sono in grado di
adattarsi dinamicamente al contesto di lavoro, qualora non fosse richiesta un’eccessiva
complessità di calcolo, la frequenza di lavoro della CPU potrebbe quindi ridursi
permettendo un risparmio di corrente, come accade ad esempio con la tecnologia DVFS, la
quale viene implementata su gran parte delle CPU e apporta ad esse la capacità di adattare
la frequenza di lavoro in base alle necessità. E’ facile capire che un aumento eccessivo della
frequenza di clock, causa spesso un degrado dell’efficienza energetica. Questa è una
problematica che attanaglia ogni tipologia di CPU, sia multiprocessore che multicore.
Le soluzioni che vengono adottate generalmente si dividono in due categorie: si può
decidere di adottare uno scheduler partizionato, ossia per un dato task, ciascuna sua
esecuzione può avvenire sempre sullo stesso core, oppure si può adottare uno scheduler di
tipo globale che permette le esecuzioni di un task su core differenti, ma restano soluzioni di
tipo euristiche.
Un metodo di schedulazione introdotto di recente per il contenimento del consumo di
energia è il Power Aware Scheduling of fixed priority tasks in Soft Real-Time Multicore
System (PAS-SRTMS). La particolarità dell’algoritmo PAS-SRTMS è che opera sia con
uno scheduling statico (Offline method) sia uno scheduling di tipo dinamico (Online
method). Grazie a tale algoritmo è possibile ridurre il consumo di potenza nei sistemi
16
multicore nei sistemi Soft real-time avvalendosi della tecnologia DVFS.
3.1 Algoritmo di scheduling PAS-SRTMS
L’algoritmo di Power Aware Scheduling of fixed priority tasks in Soft Real-Time Multicore
System innanzitutto nasce per sistemi di tipo Soft Real-Time e si basa su priorità fisse
assegnate attraverso tecniche come Deadline Monotonic (DM), Rate Monotonic (RM) etc.
Per semplicità useremo DM, indi i task con deadline più grandi assumeranno delle priorità
inferiori e viceversa.
Come già detto l’algoritmo può essere visto come il connubio di due metodi, offline e online.
Esso consiste nello scegliere frequenze di lavoro crescenti da assegnare ai core, in modo che
nello step successivo i task vengano assegnati ai core sulla base della priorità, in modo
proporzionale.

Il metodo offline viene usato per la ricerca e il settaggio della tensione e della
17
frequenza ottimale dei core. Ad esempio se prendiamo un processore con due core
(core A e core B), l’algoritmo dovrà dividere l’insieme dei task in due categorie,
quella ad alta e quella a bassa priorità. Ad esempio, nel nostro caso, usando Deadline
Monotonic, vediamo in figura che alla seconda riga avviene l’assegnazione delle
priorità. Dalla settima inizia la procedura di settaggio della tensione e della
frequenza ai core. Più in basso, alla riga 17, avviene la ricerca della tensione e della
frequenza minima che al contempo garantisce la schedulabilità. Si nota che queste
righe restano all’interno del costrutto for della settima riga, questo vuol dire che il
processo viene iterato un numero di volte sufficiente a trovare il miglior
compromesso tra consumo energetico e schedulabilità.

Il metodo online prende coscienza del lavoro svolto allo step precedente e si
preoccupa di schedulare i task. Possiamo vedere nell’esempio riportato sotto, che
l’algoritmo prende dalla coda Ready i task, verifica la priorità e assegna il task al
core corrispondente. Viene poi effettuato un resoconto di eventuali deadline sforate
e della potenza dissipata.
18
L’algoritmo ammette la possibilità che possano capitare delle deadline misses, questo
perché è impiegato per sistemi di tipo Soft Real-Time, ossia i vincoli temporali sono imposti
al solo scopo di garantire un adeguato standard prestazionale e nel caso non venissero
rispettati ciò non inficerebbe in alcun modo la sicurezza degli utenti o di quanti hanno
contatto con il sistema.
19
Capitolo 4: Bilanciamento del carico computazionale
Per sfruttare appieno i processori multicore, le applicazioni real-time dovrebbero fornire un
elevato grado di parallelismo, grazie al quale i task real-time possono utilizzare più core in
contemporanea. Per garantire delle prestazioni real-time, rendendo l’uso della CPU
efficiente, è richiesta una schedulazione di alta complessità capace anche di distribuire il
carico in modo bilanciato su tutti i core, una caratteristica che al contempo permette di
ottenere una riduzione anche dei costi energetici.
Molti metodi di scheduling real-time per piattaforme multicore proposti si focalizzano
sull’efficacia della schedulabilità o del load balancing, ma mai su entrambi (spesso due
caratteristiche mutuamente esclusive).
Una prima soluzione proposta dal Computer Science Laboratory Samsung di San Josè,
California, consiste in un approccio separatista, focalizzando l’attenzione ai processi
indipendenti per cui non ci sono chiari vincoli inter-task o relazioni. Il metodo si chiama
Load Balancing based Task Partitioning (LBTP), il quale rende i task schedulabili in scenari
complessi e, allo stesso tempo, fornisce un effettiva capacità di bilanciamento del carico.
Il meccanismo di ripartizione dei task viene eseguito senza effettuare un test di
schedulabilità durante la divisione dei processi ma con un test di bilanciamento del carico,
garantendo al contempo un soddisfacente rispetto dei vincoli di deadline. Il meccanismo si
ferma quando non può più effettuare operazioni di bilanciamento o quando oppure quando
le migliorie sono di lieve entità e questa caratteristica riduce l’overhead causato dalla
ripartizione.
L’ LBTP non si propone come il miglior algoritmo di schedulazione per piattaforme
multicore ma solo come miglior compromesso tra capacità di schedulazione e bilanciamento
del carico.
4.1 System Model, Assunzioni e Notazioni
Consideriamo un set di Task 𝑇 = {𝑡1 , 𝑡2 , … , 𝑡𝑛 }, dove 𝑛 è il numero di task, e un omogeneo
20
sistema multicore 𝐶 = {𝑐1 , 𝑐2 , … , 𝑐𝑚 }, dove m è il numero di core. Ciascun task 𝑡𝑖 è
caratterizzato dalla coppia (𝑒𝑖 , 𝑝𝑖 ), dove 𝑒𝑖 è il worst case execution time (WCET) del task
𝑡𝑖 e 𝑝𝑖 è il periodo di task 𝑡𝑖 . Assumiamo che il periodo è implicitamente uguale alla relativa
deadline. Il grado di utilizzazione dei task 𝑡𝑖 , 𝑢𝑖 , è rappresentato da 𝑢𝑖 = 𝑒𝑖 /𝑝𝑖 .
𝑒
L’utilizzazione totale del set di task 𝑇, 𝑈𝑡𝑜𝑡 è data da 𝑈𝑡𝑜𝑡 = ∑𝑛𝑖=1 𝑢𝑖 = ∑𝑛𝑖=1(𝑝𝑖 ). Si noti
𝑖
che la condizione necessaria di fattibile schedulabilità sugli m core identici è che il fattore
di utilizzazione non sia maggiore della capacità totale di calcolo del sistema.
𝑈𝑡𝑜𝑡 ≤ 𝑚
L’insieme di task assegnati al core 𝑐𝑖 è denotato con Π𝑖 . Conseguentemente l’utilizzazione
di un core dato un task assegnato ad un core, sarà 𝑈𝑖 = ∑𝑡𝑘 ∈Π𝑖 𝑢𝑘 .
Un task sarà schedulabile se e solo se tutte le sue istanze vengono completate entro le
deadline.
Per quanto riguarda il load balance, introduciamo un metodo di quantificazione, definito
come il coefficiente di variazione, ossia il rapporto tra deviazione standard del carico tra i
nuclei e il carico medio.
La misura dello squilibrio ci dà la deviazione dal corrente schema di bilanciamento del
carico rispetto a un bilanciamento perfetto. La deviazione standard di un assegnazione, 𝜎, è
𝑈
𝑖
rappresentata da 𝜎 = √(𝑈𝑖 − 𝜇)2 dove 𝜇 = ∑𝑚
𝑖=1 𝑚 (ossia il valore di utilizzazione del
core). Maggiore è il valore di squilibrio, minore è l’efficacia di bilanciamento del carico.
Infine introduciamo una proposizione utile in seguito per lo studio di schedulabilità.
Proposizione 3.1. Esiste uno squilibrio di carico se e solo se per due core, 𝑐𝑖 𝑒 𝑐𝑗 , si verifica
che 𝑈𝑖 − 𝑈𝑗 > 𝑢𝑘 , laddove 𝑡𝑘 ∈ Π𝑖 .
4.2 Scheduler Real-Time di Partizionamento
L’algoritmo di schedulazione usato per il partizionamento è stato realizzato partendo dalla
riduzione della problematica di schedulazione nei processori multipli ad un insieme di
problemi per processori singoli.
L’approccio consiste in due step. Nel primo si assegna ciascun task ad un core in modo che
21
venga rispettata la propria deadline. I processi possono essere ordinati secondo i criteri più
comuni (per deadline, per utilizzazione etc.). Nel secondo step, una volta assegnati i task,
viene applicato un algoritmo di schedulazione per sistemi uniprocessori (come EDF, RM
etc.) per schedulare i task assegnati all’interno della time line di ciascun core.
4.3 Load Balancing Based Task Partitioning (LBTP)
Entriamo adesso nel dettaglio dell’algoritmo LBTP (Load Balancing based Task
Partitioning). Esso consiste in tre step fondamentali:
1. Task ordering: I task vengono ordinati seguendo il fattore di utilizzazione in modo
decrescente.
2. Task partitioning : I task vengono assegnati al primo core libero che può soddisfare
i vincoli di deadline.
3. Task repartitioning: Questo passaggio può essere svolto solo dopo che una
schedulazione fattibile è stata trovata nello step precedente di partizionamento.
Utilizzando l’ordine inverso di ordinamento dei processi (cioè al crescere del fattore
di utilizzazione), ciascun task è riassegnato al core con la minima utilizzazione.
Questa ripartizione effettua intrinsecamente un test per il bilanciamento del carico e
non è necessario testare di nuovo la schedulabilità per ciascun task durante questa
procedura.
Il primo meccanismo di partizionamento implementato si chiama First Fit Deacresing
22
Utilization (FFDU), il quale produce una schedulabilità dalle buone performance ma
soprattutto si assicura il completamento dell’esecuzione dei task rispettando la deadline,
caratteristica fondamentale degli scheduler real-time. Durante la procedura di partizione,
ciascun task è verificato attraverso un test di schedulabilità per ciascun core disponibile,
dopodiché viene assegnato al primo tra quelli per il quale il risultato è positivo. Si passerà
al terzo step soltanto quando sarà stata trovata una soluzione praticabile dall’FFDU
assignment.
Una volta entrati nel passo successivo, entra in gioco un meccanismo di Worst-Fit per la
ripartizione dei processi, l’assegnazione avverrà con una logica diametralmente opposta. I
task vengono riassegnati in ordine crescente di utilizzazione e questa tecnica permette di
mantenere la condizione di fattibilità senza avvalersi nuovamente del test.
Questa tecnica combinata con il partizionamento Worst-Fit e l’ordinamento per
utilizzazione crescente prende il nome di Worst-Fit Increasing Utilization (WFIU). Il
meccanismo termina quando i benefici di bilanciamento non riescono più ad aumentare.
4.4 Schedulabilità in LBTP
L’algoritmo di LBTP può sempre generare una soluzione fattibile a condizione che anche
FFDU ne possa generare una, mentre il test di schedulabilità non viene eseguito durante
l’esecuzione di ripartizione.
Teorema. Se FFDU è in grado di generare una soluzione fattibile allora anche LBTP è in
grado di generare una soluzione fattibile.
Per provare questa tesi, dobbiamo partire dalla considerazione che per ciascun core, il fattore
di utilizzazione sarà minore o uguale ad 1 e che quindi tutti i vincoli di deadline possono
essere soddisfatti.
𝑈𝑖 ≤ 1, dove 𝑡𝑘 ∈ Π𝑖
(3.1)
Al core con valore di utilizzo minore, si riassegna un task e il suddetto valore non supera 1
23
in quanto l’assegnazione deve soddisfare i vincoli di deadline. Quindi il fattore di
utilizzazione non può mai essere uguale ad 1.
Supponiamo che l’utilizzo del task 𝑡𝑘 è inferiore alla differenza tra il fattore di
utilizzazione del core a cui è stato assegnato e il minore tra i fattori di utilizzazione di tutti
i core. Questo scenario comporta uno sbilanciamento del carico sulla base della
Proposizione 1.
𝑢𝑘 < 𝑈𝑖 − 𝑈𝑗 , laddove 𝑡𝑘 ∈ Π𝑖
(3.2)
In questo caso, LBTP rimuove il task 𝑡𝑘 dal core 𝑐𝑖 e lo riassegna al core 𝑐𝑗 avente il minor
fattore di utilizzazione. Ovviamente l’utilizzazione del core 𝑐𝑗 viene incrementata
dall’aggiunta di 𝑢𝑘 , ma sarà ancora minore di 1, per le (3.1), (3.2) e (3.3)
𝑈𝑗 = 𝑈𝑗 + 𝑢𝑘 < 𝑈𝑖 (3.3)
Quindi 𝑈𝑗 < 1 .
L’utilizzazione del core 𝑐𝑖 è anche inferiore ad 1 per la riduzione del valore di utilizzazione
del task 𝑡𝑘 . Si noti che 𝑢𝑘 > 0 e il fattore di utilizzazione modificato del core 𝑐𝑖 non potrà
essere 1.
𝑈𝑖 = 𝑈𝑖 − 𝑢𝑘 < 1
Il fatto che il fattore di utilizzazione dei core sia inferiore ad 1, implica che l’assegnazione
dopo la ripartizione di un task soddisfa ancora le deadline. Per la proposizione 2, il
processo si ferma quando il task successivo 𝑡𝑘 che sta per essere riassegnato, soddisfa il
seguente criterio
𝑢𝑘 ≥ (𝑈𝑚𝑎𝑥 − 𝑈𝑚𝑖𝑛 )
Giungiamo finalmente a dire che se l’assegnazione secondo FFDU soddisfa i vincoli di
deadline, allora anche l’assegnazione LBTP deve soddisfare i vincoli di deadline.
24
Capitolo 5: Applicazioni Mixed-Criticality
Le CPU multicore sono entrate con prepotenza anche nel mondo dei sistemi MixedCriticality, dove si è registrata una crescente tendenza d’uso di questi chip al fine di
allargare gli orizzonti industriali. Grazie a sofisticate tecniche di virtualizzazione, è stato
possibile integrare in un unico sistema un numero considerevole di applicazioni con livelli
di criticità differenti, noti come Safety Integrity Levels (SIL). Questi livelli esprimono il
grado di protezione richiesto contro i fallimenti, vengono usati in fase progettuale e poi
riflessi nelle fasi di sviluppo, di testing e di certificazione.
Per evitare interferenze tra applicazioni di CLs differenti coesistenti in una piattaforma
comune, gli standard di certificazione esistenti richiedono una certa indipendenza tra le
applicazioni. Si adotta quindi un isolamento spaziale e temporale su ogni core avvalendosi
di meccanismi di partizionamento a livello hardware. Purtroppo è possibile che alcune
risorse restino condivise, come ad esempio un bus o una porzione di memoria cache, per
motivi economici o anche di performance. Quindi se più core dovessero far accesso ad
esempio ad un bus di memoria, si causerebbe un’interferenza con conseguenze anche per
le applicazioni real-time.
Per incrementare l’isolamento tra i core che condividono banchi di memoria, si può
selezionare un bus di memoria schedulato staticamente oppure un server per gestire
l’accesso sulla base di un budget di accesso per ciascun core. In questo modo possiamo
facilmente quantificare gli effetti dovuti alla coesistenza delle applicazioni, sui tempi di
risposta poiché l’interferenza tra i core è limitata per costruzione. Di contro, però, la prima
soluzione è tutta a scapito della flessibilità (non possiamo modificare le politiche di
scheduling a Runtime qualora fosse necessario più spazio ad un’applicazione) e la seconda
soluzione comporta un notevole overhead e complessità progettuale.
Vestel nel 2007, per primo introdusse il modello attualmente dominante per i task MC, un
modello ripreso e modificato negli anni dalla comunità scientifica. Ma tutti i lavori
prodotti fino al 2013 non hanno mai affrontato le interferenze sulle risorse condivise e i
loro effetti sulla schedulabilità. È stato dimostrato empiricamente che il traffico sul bus di
25
memoria nei sistemi COTS può aumentare il tempo di risposta dei task nei sistemi realtime fino al 44%.
Una soluzione introdotta di recente per ovviare ai rischi di non determinismo dovuti all’uso
di risorse hardware condivise è quella del Time-Triggered and Synchronisation-based
strategy (TTS). Si tratta della prima soluzione di mixed-criticality mapping e scheduling
strategy che riesce a tenere in considerazione gli effetti temporali delle risorse condivise,
oltretutto è una soluzione implementabile su tutte le piattaforme COTS.
Viene introdotto una strategia di scheduling di partizionamento per un insieme di task MC,
il quale garantisce un isolamento temporale tra le applicazioni di differente CL, tiene conto
degli effetti dovuti alla contesa sulla memoria da parte dei task in esecuzione, aumenta
l’efficienza d’uso delle risorse. La strategia di scheduling TTS introduce un connubio tra le
attivazioni per mezzo time-triggered e event-driven e può supportare le tecniche di
prelazione a priorità fissa.
5.1 Time-Triggered and Synchronisation-based strategy (TTS)
Nei sistemi multicore in cui l’interferenza sulle risorse condivise non può essere evitata o
limitata, una soluzione può essere quella di imporre un isolamento temporale tra i diversi
livelli CS per concedere soltanto ai task di pari grado di essere eseguiti assieme.
Con l’algoritmo TTS si è assunto che sulla piattaforma sia possibile realizzare un clock
sincronizzato tra i core. L’algoritmo di scheduling avrà una periodicità uguale
all’iperperiodo 𝐻 dell’insieme dei task 𝜏, ossia il minimo comune multiplo di tutti i periodi.
Il ciclo di scheduling consiste in frames che inizia e finisce simultaneamente su tutti i core.
Ciascun frame può essere di lunghezza diversa ma fissa, e la dimensione massima è ristretta
al minimo periodo in 𝜏. Ciascun frame viene diviso in tante sub-frames quanti sono i livelli
di criticità nel sistema.
L’avvio di una sub-frame di TTS non è temporizzato, ma avviene attraverso la
sincronizzazione inter-core
con un meccanismo di barriera che guarda all’efficienza
26
d’utilizzo delle risorse.
Un nuovo subframe TTS inizia quando tutti i task schedulati nel precedente subframe sono
stati terminati su tutti i core. I task che sono schedulati entro uno stesso subframe sono
definiti dallo stesso livello di criticità e la cardinalità dei subframe di uno stesso frame
corrisponde all’inverso del grado di criticità. La schedulazione su ciascun core all’interno
di un subframe è sequenziale e segue un ordine prefissato, ciascun task viene attivato solo
al termine del precedente.
5.2 Policy
Data una schedulazione S fattibile e un funzione di barriera, vediamo il comportamento
dello scheduler su ciascun core. L’esecuzione dei processi all’interno di un frame 𝑓 ∈ 𝐹
avviene con i seguenti passaggi:
1. Per l’i-esimo subframe, lo scheduler sollecita in sequenza gli job corrispondenti sulla
base della tabella di schedulazione S e al termina segnala l’evento per poi mettersi in
attesa fino alla barrier syncronisation di tutti i core.
2. Finito il tempo di attesa, si cerca il livello di criticità 𝑙 che soddisfa la seguente
relazione
𝑡 ≤ min𝑙∈{1,…,𝐿} {𝑏𝑎𝑟𝑟𝑖𝑒𝑟𝑒(𝑓, 𝑙)𝑖 }
Lo scheduler attiverà i job nel subframe successivo, in modo che i task con grado di
criticità inferiore di 𝑙 vengano attivati con degraded mode, qualora però 𝑙 fosse
unitario, allora i job verrebbero attivati nel subframe successivo in 𝑛𝑜𝑟𝑚𝑎𝑙𝑒 𝑚𝑜𝑑𝑒.
La decisione sulla modalità di esecuzione del task nel subframe che segue, riguarda
solo il frame corrente e non è rilevante per quello successivo.
3. Gli steps precedenti vengono ripetuti per tutti i subframe fino a che non si arrivi al
frame successivo.
Qualora non venisse raggiunta la barrier syncronisation nei tempi stabiliti, sarà sintomo di
un comportamento bacato, in quanto in conflitto con la fattibilità della schedulazione
27
adottata.
E’ facile capire il motivo per cui questa soluzione si può adattare a tutte le architetture
COTS, la concorrenza sulle risorse non deve quindi essere eliminata con meccanismi
hardware. Inoltre si è rafforzato l’isolamento temporale tra i livelli di criticità CL
permettendo quindi la certificazione incrementale. Infine è interessante notare come è
stato possibile aumentare l’efficienza d’uso delle risorse: i subframe vengono adattati al
contesto dinamicamente, in base ai profili dei task in esecuzione. Se un task di livello
superiore presenta un profilo di esecuzione di livello 𝑙 > 1, si può forzare la modalità
d’esecuzione dei task per portarli in degraded mode, questa variazione durerà soltanto il
tempo di un frame TTS e non sarà in alcun modo permanente.
5.3 Schedulabilità e certificazione in TTS
Dato un insieme di task 𝜏, l’ammissibilità di una schedulazione S è data dal rispetto della
relazione che segue sulla base delle rispettive barriers(𝑓, 𝑙) dei frame 𝑓 ∈ 𝐹 e dei livelli di
criticità 𝑙 ∈ {1, … , 𝐿},
𝑏𝑎𝑟𝑟𝑖𝑒𝑟𝑠(𝑓, 𝑙)𝑖 ≤ 𝐿𝑓 , ∀𝑓 ∈ 𝐹
28
Dove 𝐿𝑓 indica la lunghezza di un frame 𝑓. Soltanto se la relazione è soddisfatta per
ciascun frame e, ovviamente, è garantito il rispetto di ciascuna deadline, la schedulazione
può dirsi fattibile secondo TTS.
Per poter certificare il sistema è quindi necessario conoscere il comportamento su tutti i
livelli di criticità, la peculiarità di questo algoritmo sta nel fatto che la variabilità dei tempi
di risposta viene appiattita dalle funzioni di barriera, quindi il comportamento su ciascun
livello di criticità è sempre prevedibile.
29
Conclusioni
E’ innegabile che l’impiego delle piattaforme multicore abbia allargato in modo
considerevole gli orizzonti dei Sistemi Real-Time, ma forse è ancora presto per affermare
che i tempi per questa tecnologia siano maturi.
Oltretutto con queste nuove CPU, i campi di ricerca si sono moltiplicati, infatti in questo
elaborato sono stati presi in esame, per forza di cose, solo 4 algoritmi di scheduling,
ciascuno ideato per la risoluzione di un solo problema. Ovviamente per quel singolo
problema, sono state proposte numerose altre soluzioni e in questo elaborato sono state
riportate soltanto le più recenti.
Possiamo notare che per tutti e 4 siamo dovuti scendere a compromessi. Ad esempio il
primo algoritmo analizzato, Mpn, riesce a creare un algoritmo capace di schedulare in
scenari differenti a seconda delle proprietà di prelazione, ma non garantisce un adeguato
bilanciamento del carico. L’inefficace bilanciamento del carico comporta una serie di
problematiche ampiamente trattati in questo elaborato. Il secondo algoritmo, LBTP, invece
si focalizza proprio sul problema del load balancing ma dal canto suo necessita che i task
siano completamente indipendenti tra loro. Il PAS-SRTMS è un algoritmo che può essere
applicato soltanto in sistemi di tipo Soft Real-Time, questo è un problema in quanto
preclude il suo impiego in una miriade di sistemi dotati di autonomia energetica. Infine per
l’algoritmo TTS c’è da dire che è possibile impiegarlo in molteplici configurazioni
hardware per la sua elevata portabilità, tuttavia non può essere di tipo preemptive.
Se andassimo ad analizzare altri algoritmi dello state-of-art, il discorso non cambierebbe,
le soluzioni trovate vanno ad ovviare soltanto alcuni aspetti delle problematiche più
comuni.
Possiamo concludere dicendo che a 10 anni dall’esplosione del mercato dei processori
multicore, la ricerca scientifica sui meccanismi di scheduling Real-Time si ritrova ancora
molta strada da percorre. Per progetti di importanza minore è già possibile adottare
30
molteplici soluzioni, molte delle quali anche ben testate e impiegate ordinariamente, ma
nei casi in cui l’affidabilità richiesta in un sistema sia una proprietà molto forte, resta
allora al designer il compito di fare le dovute scelte progettuali per cercare il giusto
compromesso tra i requisiti richiesti e le soluzioni adottabili.
31
Bibliografia
[1]
Jinkyu Lee and Kang G. Shin, Improvement of Real-Time Multi-Core Schedulability
with Forced Non-Preemption, IEEE Transactions on Parallel and Distributed Systems, vol.
25, pp. 1233 - 1243, May 2014.
[2]
Georgia Giannopoulou, Nikolay Stoimenov, Pengcheng Huang, Lothar Thiele,
Scheduling of Mixed-Criticality Applications on Resource-Sharing Multicore Systems,
Embedded Software (EMSOFT), IEEE Proceedings of the International Conference, 1 – 25,
Oct 2013.
[3]
Sanjoy Baruah, Vincenzo Bonifaci, Gianlorenzo D’Angelo, Haohan Li, Alberto
Marchetti-Spaccamela, Nicole Megow, and Leen Stougie, Scheduling Real-Time MixedCriticality Jobs, IEEE Transactions on Computers, vol. 61, pp. 1140 - 1152, Aug 2012.
[4]
Jaeyeon Kang and Daniel G.Waddington, Load Balancing Aware Real-Time Task
Partitioning in Multicore Systems, IEEE International Conference on Embedded and RealTime Computing Systems and Applications, pp. 404 - 408, 2012.
[5]
Giorgio C. Buttazzo, Sistemi in Tempo Reale, Pitagora editore, 2006.
[6]
Hang Su Univ. of Texas at San Antonio, San Antonio, TX, USA Dakai Zhu ; Mosse,
D., Load Balancing Aware Real-Time Task Partitioning in Multicore Systems, IEEE
Embedded and Real-Time Computing Systems and Applications (RTCSA), 19th
International Conference on, pp. 352 - 357, 2013
[7]
R . Pellizzoni, B . D . B u i , M . Caccamo, and L . Sha. Coscheduling of cpu and i/o
transactions in cots-based embedded systems. In RTSS, pp 221 - 231, 2008.
[8]
Wikipedia, http://en.wikipedia.org/wiki/Dynamic_voltage_scaling, 20 Feb 2015.
[9]
K. Hakkim Ansari, P. Chitra and P. Sonaiyakarthick, Power-Aware Scheduling of
Fixed Priority Tasks in Soft Real-Time Multicore Systems, In ICECCN, pp 496 - 502, 2013.
[10] Jinkyu Lee, Member, IEEE, and Insik Shin, Member, IEEEEDZL Schedulability
Analysis in Real-Time Multicore Scheduling, IEEE Transactions on software Engineering,
pp. 910 - 916, 2013
[11] G. Giannopoulou, K. Lampka, N. Stoimenov, and L. Thiele, Timed model checking
with abstract ions: toward s worst-case response time analysis in resource-sharing manycore
32
systems, In EMSOFT, pp 63 - 72, 2012
[12] G. Giannopoulou, K. Lampka, N. Stoimenov, and L. Thiele, Timed model checking
with abstract ions: toward s worst-case response time analysis in resource-sharing manycore
systems, In EMSOFT, pp 63 - 72, 2012
[13] B. B. Brandenburg, J. M. Calandrino, and J. H. Anderson, On the scalability of realtime scheduling algorithms on multicore platforms: A case study, Proc. IEEE Real-Time
Systems Symp. RTSS, pp. 157-169, Dec 2008
33