dipartimento di elettronica, informazione e bioingegneria ... · l'analisi e la stima delle...
Post on 19-Jul-2018
216 Views
Preview:
TRANSCRIPT
Politecnico di Milano
Scuola di Ingegneria Industriale e dell'Informazione
Dipartimento di Elettronica, Informazione e Bioingegneria
Corso di Laurea Magistrale in Ingegneria Informatica
Productivity: una nuova metrica per l'analisi
di performance nei processori multi-core e
multi-thread
Relatore: Prof. Marco GRIBAUDO
Correlatore: Ing. Stefano DONI
Tesi di Laurea di:
Francesco GIGLIOLI
Matr. 821178
Anno Accademico 2014�2015
A Tiziana e Pierino,
a Valentina,
a Gabriele e Massimiliano.
Ringraziamenti
Desidero ringraziare la mia famiglia, che mi ha sempre sostenuto in questo per-
corso di studi. Ringrazio Valentina, per essermi sempre stata vicina. Ringrazio i
colleghi dell'azienda Moviri S.p.A. per avermi permesso di svolgere presso di loro
questo lavoro di tesi. In particolar modo ringrazio Stefano, che mi ha seguito in
questo periodo e dal quale ho potuto imparare molto. In�ne ringrazio ogni persona
il cui cammino si è, in un qualche modo, incrociato col mio in questi anni.
Indice
Introduzione 1
1 Stato dell'arte 4
1.1 Tecnologie dei moderni microprocessori . . . . . . . . . . . . . . . . . 4
1.1.1 Architetture Multiprocessore . . . . . . . . . . . . . . . . . . 4
1.1.2 Architetture Multi-Core . . . . . . . . . . . . . . . . . . . . . 5
1.1.3 Pipeline e Instruction Level Parallelism (ILP) . . . . . . . . . 6
1.1.4 Processori superscalari . . . . . . . . . . . . . . . . . . . . . . 8
1.1.5 Simultaneous multithreading (SMT) . . . . . . . . . . . . . . 9
1.1.5.1 Intel Hyper-Threading Technology . . . . . . . . . . 11
1.1.6 Dynamic frequency and voltage scaling . . . . . . . . . . . . . 13
1.1.6.1 Processor states . . . . . . . . . . . . . . . . . . . . 14
1.1.6.2 Performance states . . . . . . . . . . . . . . . . . . . 14
1.1.6.3 Intel Turbo Boost . . . . . . . . . . . . . . . . . . . 15
1.1.7 Model-speci�c registers . . . . . . . . . . . . . . . . . . . . . . 16
1.1.7.1 Hardware performance counters . . . . . . . . . . . 16
1.2 Modelli e metriche di performance tradizionali . . . . . . . . . . . . . 18
1.2.1 Operational analysis . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 Modello tradizionale per la stima dell'utilizzo . . . . . . . . . 22
1.3 Tools di monitoraggio e reportistica . . . . . . . . . . . . . . . . . . . 24
1.3.1 Top . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3.2 Vmstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.3 Turbostat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.4 Sar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.5 Perf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3.6 Intel Performance Counter Monitor (PCM) . . . . . . . . . . 30
1.4 Software di benchmarking . . . . . . . . . . . . . . . . . . . . . . . . 31
1.4.1 RUBBoS: Bulletin Board Benchmark . . . . . . . . . . . . . . 32
1.4.2 CBench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.4.3 SPECpower_ssj 2008 . . . . . . . . . . . . . . . . . . . . . . 33
i
Indice
2 Motivazioni 35
2.1 Critica alle metriche tradizionali di utilizzo . . . . . . . . . . . . . . 35
2.1.1 Utilizzo del processore (CPU time) . . . . . . . . . . . . . . . 35
2.1.1.1 Intel Corporation . . . . . . . . . . . . . . . . . . . 35
2.1.1.2 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1.1.3 Microsoft Corporation . . . . . . . . . . . . . . . . . 37
2.1.1.4 Adrian Cockroft (Net�ix, eBay, Sun) . . . . . . . . . 38
2.1.2 Load average . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.2 Metriche alternative . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.1 Intel Corporation . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2.2 IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.3 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2.4 VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.5 Adrian Cockroft . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3 Limiti della metrica di utilizzo . . . . . . . . . . . . . . . . . . . . . . 45
2.3.1 Problema 1: Hyper-Threading . . . . . . . . . . . . . . . . . . 46
2.3.2 Problema 2: Dynamic frequency scaling . . . . . . . . . . . . 46
2.4 Capacity planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3 Modello proposto 49
3.1 La produttività del processore . . . . . . . . . . . . . . . . . . . . . . 49
3.1.1 Densità dei thread . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.2 Instructions per Cycle (IPC) . . . . . . . . . . . . . . . . . . 52
3.1.3 Ricavare la metrica . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.4 Problema 1: Hyper-Threading . . . . . . . . . . . . . . . . . . 54
3.1.5 Problema 2: Dynamic frequency scaling . . . . . . . . . . . . 55
3.1.6 Applicabilità della metrica . . . . . . . . . . . . . . . . . . . . 55
3.2 Raccolta dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.1 Monitoring dell'applicazione . . . . . . . . . . . . . . . . . . . 56
3.2.2 Informazioni sul sistema . . . . . . . . . . . . . . . . . . . . . 56
3.3 Calcolare altre metriche con i PC . . . . . . . . . . . . . . . . . . . . 57
3.3.1 Average Thread Density (ATD) . . . . . . . . . . . . . . . . . 58
3.3.2 Core Busy Time (CBT) . . . . . . . . . . . . . . . . . . . . . 58
3.3.3 Instructions per Cycle (IPC) . . . . . . . . . . . . . . . . . . 58
3.3.4 Active Frequency (AFREQ) . . . . . . . . . . . . . . . . . . . 59
4 MTperf 60
4.1 LaunchCollectors.py . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.1 Operazioni preliminari . . . . . . . . . . . . . . . . . . . . . . 61
4.1.2 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.3 Elaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
ii
Indice
4.1.4 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2 Main.py: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.1 Operazioni preliminari . . . . . . . . . . . . . . . . . . . . . . 63
4.2.2 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.2.3 Elaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2.3.1 Importazione dei dati . . . . . . . . . . . . . . . . . 65
4.2.3.2 Creazione dei dataset . . . . . . . . . . . . . . . . . 66
4.2.3.3 Stima della productivity . . . . . . . . . . . . . . . . 66
4.2.3.4 Altre metriche . . . . . . . . . . . . . . . . . . . . . 67
4.2.3.5 Gra�ci . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2.4 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.3 Main-live.py: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3.1 Operazioni preliminari . . . . . . . . . . . . . . . . . . . . . . 69
4.3.2 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3.3 Elaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3.4 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5 Validazione sperimentale 74
5.1 Sistema sotto test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.3 Esperimenti con RUBBoS . . . . . . . . . . . . . . . . . . . . . . . . 77
5.3.1 Con�gurazione di una run . . . . . . . . . . . . . . . . . . . . 77
5.3.2 SUT in con�gurazioni standard . . . . . . . . . . . . . . . . . 78
5.3.2.1 TC1: Governor powersave . . . . . . . . . . . . . . . 78
5.3.2.2 TC3: Governor performance . . . . . . . . . . . . . 82
5.3.3 SUT con Turbo Boost non attivo . . . . . . . . . . . . . . . . 83
5.3.4 SUT con Hyper-Threading non attivo . . . . . . . . . . . . . 86
5.3.5 Esperimenti a frequenze crescenti . . . . . . . . . . . . . . . . 89
5.4 Esperimenti con CBench . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.4.1 Con�gurazione di una run . . . . . . . . . . . . . . . . . . . . 95
5.4.2 SUT in con�gurazioni standard . . . . . . . . . . . . . . . . . 97
5.4.2.1 TC1: Governor powersave . . . . . . . . . . . . . . . 97
5.4.2.2 TC3: Governor performance . . . . . . . . . . . . . 100
5.5 Esperimenti con SPECpower_ssj 2008 . . . . . . . . . . . . . . . . . 101
5.5.1 Con�gurazione di una run . . . . . . . . . . . . . . . . . . . . 102
5.5.2 SUT in con�gurazioni standard . . . . . . . . . . . . . . . . . 103
5.5.2.1 TC1: Governor powersave . . . . . . . . . . . . . . . 103
5.5.2.2 TC3: Governor performance . . . . . . . . . . . . . 105
5.5.3 Esperimenti con HT e TB non attivi . . . . . . . . . . . . . . 106
5.5.3.1 TC6: Governor powersave . . . . . . . . . . . . . . . 108
iii
Indice
5.5.3.2 TC8: Governor performance . . . . . . . . . . . . . 110
6 Sintesi dei risultati 115
Conclusioni 119
Bibliogra�a 124
iv
Elenco delle �gure
1.1 Sistema monoprocessore single core . . . . . . . . . . . . . . . . . . . 5
1.2 Architettura multiprocessore single core . . . . . . . . . . . . . . . . 5
1.3 Monoprocessore dual core . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Multiprocessore con quattro core . . . . . . . . . . . . . . . . . . . . 7
1.5 Esecuzione tradizionale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Pipeline 5 stadi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 Pipeline superscalare 5 stadi, 2-issue . . . . . . . . . . . . . . . . . . 9
1.8 Implementazioni del multithreading . . . . . . . . . . . . . . . . . . . 10
1.9 Scheduling di thread in SMT . . . . . . . . . . . . . . . . . . . . . . 11
1.10 Processore dual core con SMT . . . . . . . . . . . . . . . . . . . . . . 12
1.11 Intel Hyper-Threading Technology . . . . . . . . . . . . . . . . . . . 12
1.12 Intel Turbo Boost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.13 Coda M/M/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.14 Utilizzo sistema M/M/1 di esempio . . . . . . . . . . . . . . . . . . . 23
1.15 Tempi di risposta sistema M/M/1 di esempio . . . . . . . . . . . . . 24
1.16 Top screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.17 Vmstat screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.18 Turbostat screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.19 Sar screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.20 Perf screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.21 PCM screenshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.1 Utilizzo sistema con HT di esempio . . . . . . . . . . . . . . . . . . . 47
3.1 Core �sico con solo il primo thread attivo . . . . . . . . . . . . . . . 50
3.2 Core �sico con entrambi i thread attivi . . . . . . . . . . . . . . . . . 51
3.3 Core �sico con TD variabile . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 MTperf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2 RUBBoS TC1: U vs X . . . . . . . . . . . . . . . . . . . . . . . . . . 79
v
Elenco delle �gure
5.3 RUBBoS TC1: P vs X . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4 RUBBoS TC1: R vs U . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.5 RUBBoS TC1: ATD vs X . . . . . . . . . . . . . . . . . . . . . . . . 82
5.6 RUBBoS TC4: U vs X . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.7 RUBBoS TC4: P vs X . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.8 RUBBoS TC4: R vs P . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.9 RUBBoS TC4: ATD vs X . . . . . . . . . . . . . . . . . . . . . . . . 89
5.10 RUBBoS TC7: U vs X . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.11 RUBBoS TC7: P vs X . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.12 RUBBoS TC7: ATD vs X . . . . . . . . . . . . . . . . . . . . . . . . 92
5.13 RUBBoS Frequenze Crescenti: U vs X . . . . . . . . . . . . . . . . . 94
5.14 RUBBoS Frequenze Crescenti: P vs X . . . . . . . . . . . . . . . . . 95
5.15 RUBBoS Frequenze Crescenti: ATD vs X . . . . . . . . . . . . . . . 96
5.16 CBench TC1: U, AFREQ vs X . . . . . . . . . . . . . . . . . . . . . 98
5.17 CBench TC1: P vs X . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.18 CBench TC1: R vs U . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.19 CBench TC3: R vs U . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.20 SPECpower TC1: U, AFREQ vs X . . . . . . . . . . . . . . . . . . . 104
5.21 SPECpower TC1: P vs X . . . . . . . . . . . . . . . . . . . . . . . . 105
5.22 SPECpower TC1: ATD vs X . . . . . . . . . . . . . . . . . . . . . . 106
5.23 SPECpower TC3: U vs X . . . . . . . . . . . . . . . . . . . . . . . . 108
5.24 SPECpower TC6: P vs X . . . . . . . . . . . . . . . . . . . . . . . . 110
5.25 SPECpower TC6: U vs X . . . . . . . . . . . . . . . . . . . . . . . . 111
5.26 SPECpower TC8: R vs U . . . . . . . . . . . . . . . . . . . . . . . . 113
5.27 SPECpower TC8: U vs X . . . . . . . . . . . . . . . . . . . . . . . . 114
5.28 SPECpower TC8: P vs X . . . . . . . . . . . . . . . . . . . . . . . . 114
6.1 RUBBoS: Percentuali di stima del throughput . . . . . . . . . . . . . 117
6.2 RUBBoS a frequenze crescenti: Percentuali di stima del throughput . 117
6.3 CBench: Percentuali di stima del throughput . . . . . . . . . . . . . 118
6.4 SPECpower: Percentuali di stima del throughput . . . . . . . . . . . 118
vi
Elenco delle tabelle
1.1 Intel implementation policies . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Intel Pre-de�ned Architectural Performance Events . . . . . . . . . . 17
1.3 Intel Pre-de�ned Fixed-Function PC . . . . . . . . . . . . . . . . . . 18
5.1 RUBBoS TC1: R2 e MAE a confronto . . . . . . . . . . . . . . . . . 80
5.2 RUBBoS TC1: powersave . . . . . . . . . . . . . . . . . . . . . . . . 83
5.3 RUBBoS TC3: R2 e MAE a confronto . . . . . . . . . . . . . . . . . 83
5.4 RUBBoS TC3: performance . . . . . . . . . . . . . . . . . . . . . . . 84
5.5 RUBBoS TC4: R2 e MAE a confronto . . . . . . . . . . . . . . . . . 84
5.6 RUBBoS TC4: TB o� . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.7 RUBBoS TC7: R2 e MAE a confronto . . . . . . . . . . . . . . . . . 88
5.8 RUBBoS TC7: HT o� . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.9 RUBBoS Frequenze Crescenti: R2 e MAE a confronto . . . . . . . . 93
5.10 RUBBoS Frequenze Crescenti: metriche a confronto . . . . . . . . . 93
5.11 CBench TC1: R2 e MAE a confronto . . . . . . . . . . . . . . . . . . 98
5.12 CBench TC1: powersave . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.13 CBench TC3: performance . . . . . . . . . . . . . . . . . . . . . . . . 103
5.14 CBench TC3: R2 e MAE a confronto . . . . . . . . . . . . . . . . . . 103
5.15 SPECpower TC1: R2 e MAE a confronto . . . . . . . . . . . . . . . 104
5.16 SPECpower TC1: powersave . . . . . . . . . . . . . . . . . . . . . . 107
5.17 SPECpower TC3: R2 e MAE a confronto . . . . . . . . . . . . . . . 107
5.18 SPECpower TC3: performance . . . . . . . . . . . . . . . . . . . . . 107
5.19 SPECpower TC6: powersave . . . . . . . . . . . . . . . . . . . . . . 109
5.20 SPECpower TC6: R2 e MAE a confronto . . . . . . . . . . . . . . . 109
5.21 SPECpower TC6: Service Demand . . . . . . . . . . . . . . . . . . . 112
5.22 SPECpower TC8: performance . . . . . . . . . . . . . . . . . . . . . 112
5.23 SPECpower TC8: R2 e MAE a confronto . . . . . . . . . . . . . . . 113
vii
Elenco dei listati
4.1 Estratto di LaunchCollectors.py . . . . . . . . . . . . . . . . . . . . . 62
4.2 Estratto di Main.py: frequenze del processore . . . . . . . . . . . . . 66
4.3 Estratto di Main.py: stima degli IPC . . . . . . . . . . . . . . . . . . 72
4.4 Estratto di Main.py: stima delle AFREQ . . . . . . . . . . . . . . . 73
viii
Sommario
Lo studio delle performance dei sistemi informatici è un campo ingegneristico dal
solido background storico e tecnico. Oggigiorno questo campo deve iniziare a prende-
re in considerazione le molteplici nuove tecnologie che si sono a�ermate nell'ambito
delle architetture dei calcolatori elettronici, come l'avvento dei sistemi multi-core, il
simultaneous multithreading e le tecniche di dynamic frequency scaling.
Scopo della tesi è quindi includere tali tecnologie nello studio di metriche di
performance alternative a quelle tradizionali, tramite le quali si possa conoscere lo
stato reale del sistema in modo sempre più fedele. A questo si aggiunge la capacità di
poter e�ettuare stime delle performance degli elaboratori sempre più precise rispetto
a quelle che vengono svolte oggi. In particolare il focus di questa tesi è lo studio di
una metrica alternativa a quella di utilizzo di un processore, a cui sono state mosse
molte critiche circa la sua reale a�dabilità nei sistemi odierni.
Sfruttando tecnologie innovative è stato elaborato un modello il cui risultato è
una nuova metrica di misurazione dell'utilizzo del sistema, chiamata productivity. Si
è quindi studiato il comportamento di tale metrica su un sistema posto sotto carico
da diversi benchmark. I dati raccolti dal monitoraggio del sistema hanno permesso
l'analisi e la stima delle sue performance sia tramite il modello tradizionale sia tramite
il modello proposto. Nei casi e nelle condizioni studiate, la productivity si è rivelata
essere molto più accurata della metrica tradizionale di utilizzo, permettendo di avere
una visione nuova di quanto il sistema fosse realmente utilizzato. Per supportare la
raccolta e l'elaborazione dei dati è stata sviluppata una suite di tool open source
disponibile online.
ix
Abstract
The study of computer systems performance is an engineering �eld with a robust
historical and technical background. Today this �eld must start considering the
multiple new technologies that established into modern computer architectures, such
as multi-core systems, simultaneous multithreading and dynamic frequency scaling
techniques.
Therefore the aim of this thesis is to include these technologies into the study
of metrics alternative to the traditional ones, through which we could understand
more precisely the real state of the system. Furthermore these metrics should be
capable to better estimate the future performances of computers with respect to the
actual estimation models. In particular the focus of this thesis is the study of a
metric alternative to the processor utilization, which received many criticisms about
its actual reliability on modern systems.
A model based on innovative technologies has been developed and its result is
a new metric of system utilization, called productivity. Then the behavior of this
metric has been studied on a system under a load generated by several benchmarks.
The data collected during the monitoring of the system were used to analyze and
to estimate the computer performances using both the traditional model and the
proposed model. In the studied cases and conditions, the productivity revealed to be
way more accurate than the traditional utilization metric, allowing a new vision of
the real system utilization level. In order to support the collection and the processing
of data it has been developed an open source tool suite, which is available online.
x
Introduzione
Il campo di analisi delle performance dei sistemi informatici vanta un'importante
tradizione storica che ha visto l'applicazione dei risultati accademici al mondo dell'in-
dustria. Questo ambito ingegneristico studia i modelli e le metriche che permettono
di rappresentare le caratteristiche e le capacità delle risorse di un sistema informatico
impegnato a svolgere un carico di lavoro. Alcune di queste metriche sono, ad esem-
pio, il tempo di risposta che il sistema impiega ad elaborare un dato lavoro, il numero
di operazioni eseguite nell'unità di tempo (throughput), la disponibilità del sistema
(uptime, downtime), l'utilizzo delle risorse computazionali e il consumo energetico.
La nascita dell'analisi operazionale e l'applicazione delle reti di code ai modelli di
performance prende il via negli anni '50, �no a diventare una disciplina a�ermata ed
utilizzata (si veda [14, 23, 26]). Oltre a de�nire le metodologie per misurare lo stato
di un sistema, tali modelli permettono anche di fare delle previsioni sull'andamento
futuro delle metriche di performance. Si possono infatti eseguire delle stime sullo
stato futuro del sistema al variare di determinate condizioni. I sistemi informatici
dell'epoca in cui si è sviluppata questa teoria erano facilmente controllabili e model-
labili poichè la visione d'insieme delle loro componenti era chiara e semplice. Con il
progredire della tecnologia tali sistemi si sono evoluti e oggi si hanno macchine con
molte componenti altamente correlate tra loro. Su queste nuove architetture sono
state introdotte una serie di tecnologie, tra le quali i nuovi processori multi-core,
il simultaneous multithreading e le tecniche di dynamic frequency scaling. Queste
macchine sono quindi drasticamente di�erenti rispetto a quelle su cui erano stati
sviluppati i modelli tradizionali. Pertanto questa diversità in�uisce sui risultati ot-
tenuti dall'analisi degli attuali sistemi tramite le leggi tradizionali, oltre ad avere
e�etti sulla previsione delle loro performance. Ci si può quindi domandare se le leggi
che erano state ottenute studiando le architetture precedenti possano ancora essere
applicate alle architetture moderne, oppure se serva rivisitare queste teorie alla luce
dell'evoluzione dei sistemi informatici.
Il punto di partenza da cui ha preso forma questa tesi è stato un problema molto
evidente nella pratica industriale di analisi delle performance, che è emerso durante
lo studio di un moderno sistema informatico. Infatti si sono osservati dei risultati
1
Introduzione
fuorvianti sia nell'analisi che nella previsione delle performance di tale sistema trami-
te l'applicazione dei modelli tradizionali. Tali risultati hanno portato ad e�ettuare
considerazioni errate dal punto di vista della capacità computazionale residua che il
sistema era in grado di o�rire, con una conseguente stima errata del carico di lavoro
che era ancora possibile somministrare. Lo scopo della tesi è quindi studiare come le
tecnologie introdotte nei moderni computer in�uiscano sul comportamento dei mo-
delli tradizionali e proporre un modello innovativo per oltrepassare i limiti attuali.
Ci si so�ermerà in particolare sulla metrica che negli ultimi anni è stata la più di-
scussa tra tutte: l'utilizzo di una CPU. Infatti da alcuni anni sono state mosse molte
critiche a questa metrica (si veda [5,20,34,39]), le quali evidenziano la sua ina�dabi-
lità proprio a causa delle nuove tecnologie introdotte nelle recenti architetture delle
CPU. Aziende come IBM, VMware e Sun (ora acquisita da Oracle) hanno già im-
plementato, tramite registri ad-hoc e modelli sviluppati internamente, una soluzione
a questo problema per i loro processori di fascia enterprise (si veda [35, 38, 43]). Ri-
mane invece carente Intel, che non ha ancora sviluppato alcun sistema proprietario.
Essendo Intel uno dei maggiori player nel mercato delle CPU è di nostro interesse
sviluppare un modello che possa essere applicato su queste architetture. Esso però è
indipendente dall'architettura su cui verrà utilizzato, in quanto i concetti teorici alla
sua base astraggono dall'architetura stessa. In questa tesi il modello verrà imple-
mentato sfruttando tecnologie o�erte nelle CPU Intel, che possono essere ritrovate
(con nomi diversi) anche su architetture di altre aziende.
Il modello proposto avrà come risultato una nuova metrica di produttività della
CPU, denominata productivity, che permetterà di ottenere un valore di utilizzo della
CPU aderente al reale stato di capacità del sistema. La productivity si rivelerà esse-
re più a�dabile rispetto all'utilizzo tradizionale sia nell'analisi che nella stima delle
performance del sistema. Sono stati utilizzati dei software di benchmarking (RUB-
BoS [2], SPECpower_ssj 2008 [11] e CBench del Politecnico di Milano) per porre
sotto stress il sistema considerato, che è stato monitorato in modo da raccogliere
dati sulle sue prestazioni. In seguito, grazie all'ausilio di una suite di programmi svi-
luppati appositamente, sono stati analizzati questi dati e si sono ottenuti i risultati
sia del modello tradizionale sia del nuovo modello basato sulla metrica di produc-
tivity. I risultati del modello proposto si sono rivelati essere decisamente positivi e
molto più precisi rispetto ai risultati ottenuti con la metrica di utilizzo tradizionale.
Conoscendo il sistema sotto test e la tipologia di carico a cui è stato sottoposto, la
productivity si è rivelata essere una metrica precisa sia nella descrizione di quanto
il sistema venisse utilizzato, sia nella previsione di quanto sarebbe stato utilizzato
il sistema all'aumentare del lavoro somministrato. Eventuali sviluppi futuri saranno
legati all'utilizzo di tale metrica in ambienti di produzione, nello speci�co sia come
tool di reportistica sia come accurato strumento di previsione delle performance. Ul-
teriore lavoro potrà essere svolto nella realizzazione di un modello a reti di code che
2
Introduzione
permetta di modellare l'andamento dei tempi di risposta in relazione alla producti-
vity, in modo che si possano de�nire dei limiti per rispettare determinati vincoli di
qualità del servizio o�erto.
La tesi è strutturata nel modo seguente:
� Nel Capitolo 1 si descrive lo stato dell'arte delle tecnologie presenti sui com-
puter moderni, le metriche tradizionali e i tool di performance che vengono
utilizzati oggigiorno. Si illustrano i benchmark utilizzati e in�ne si accenna
alle implementazioni di metriche innovative elaborate da alcune aziende per i
propri sistemi.
� Nel Capitolo 2 si descrivono le motivazioni che hanno portato allo svolgimento
di questo studio, con riferimento alle problematiche evidenziate da importanti
aziende del settore.
� Nel Capitolo 3 si presenta il modello proposto e come esso sia stato ottenuto.
� Nel Capitolo 4 si descrive il tool che è stato sviluppato a supporto di questo
studio.
� Nel Capitolo 5 si valida il modello esponendo i risultati ottenuti dalle analisi
sugli esperimenti che sono stati eseguiti.
� Nel Capitolo 6 si sintetizzano i principali risultati ottenuti dagli esperimenti
mostrati.
� Nelle Conclusioni si termina il lavoro, indicando eventuali sviluppi futuri.
3
Capitolo 1
Stato dell'arte
1.1 Tecnologie dei moderni microprocessori
Le architetture dei moderni microprocessori presentano un gran numero di di�e-
renze sia dal punto di vista teorico che implementativo rispetto ai processori utilizzati
nei primi calcolatori. Una delle di�erenze predominanti consiste nel fatto che i pri-
mi processori eseguivano sequenzialmente una singola istruzione alla volta, mentre
i moderni microprocessori possono eseguire più istruzioni in parallelo. Questo cam-
biamento, come tanti altri nella storia delle architetture dei processori, è avvenuto
sia per raggiungere prestazioni computazionali sempre maggiori sia per sopperire a
limiti o mancanze della tecnologia. Sono state sviluppate sempre nuove strategie
nell'esecuzione delle istruzioni, che sono state implementate in architetture e com-
ponenti hardware innovative. In questa sezione verranno descritte alcune tecnologie
che hanno caratterizzano l'evoluzione dei processori.
1.1.1 Architetture Multiprocessore
Tradizionalmente i computer erano caratterizzati dall'avere un processore con
una singola CPU al suo interno (detta core �sico), la quale eseguiva tutto il lavoro
utile che le veniva richiesto (Figura 1.1). Il sistema operativo quindi poteva eseguire
un solo processo alla volta, limitando notevolmente il numero di programmi che
potevano lavorare in modo concorrente. A partire dagli anni '80 l'architettura di
questi sistemi monoprocessore è stata modi�cata in un'architettura composta da
un numero maggiore di processori identici disposti in parallelo sullo stesso chip. In
questo modo il sistema operativo poteva sfruttare le multiple risorse �siche disponibili
per eseguire contemporaneamente più processi, ognuno su un core separato. Sulla
scheda madre del computer vengono quindi montate più socket, ognuna delle quali
ospita un singolo processore con la sua cache dedicata (Figura 1.2).
La memoria principale può essere �sicamente disposta in modo centralizzato (il
cui accesso è quindi uniforme, detto UMA) o distribuito (il cui accesso è non uniforme,
4
1.1. Tecnologie dei moderni microprocessori
Figura 1.1: Schema di un processore con singolo core e relative cache. L'immagine èricavata da [13].
Figura 1.2: Schema di un'architettura multiprocessore single core. L'immagine èricavata da [13].
detto NUMA). Inoltre lo spazio degli indirizzi della memoria principale può essere
gestito in modo da essere condiviso (single logically shared address space) oppure
privato per ogni processore (multiple and private address spaces). L'architettura
più comunemente usata viene chiamata symmetric multiprocessing, che prevede che
la memoria principale sia centralizzata e condivisa tra i processori. Per gestire i
problemi di cache coherence si sono sviluppati algoritmi di comunicazione tramite
messaggi quali gli snooping protocols e i directory based protocols.
1.1.2 Architetture Multi-Core
Fino agli anni 2000 per aumentare le prestazioni dei processori si era sempre
incrementata la frequenza di lavoro della CPU, in modo da farle eseguire un numero
5
1.1. Tecnologie dei moderni microprocessori
Figura 1.3: Monoprocessore dual core. L'immagine è ricavata da [13].
maggiore di istruzioni nell'unità di tempo. L'aumento di frequenza implicava però
sia un aumento dei consumi energetici sia un aumento di calore della CPU, che
doveva essere adeguatamente dissipato. Questi limiti, presenti sia nelle architetture
monoprocessore che in quelle multiprocessore, sono stati superati grazie alle nuove
tecnologie di miniaturizzazione, che hanno permesso di sviluppare le architetture
multi core.
Questi nuovi monoprocessori contengono al loro interno due o più core �sici
identici (Figura 1.3) che eseguono in modo indipendente ma sincronizzato le istruzioni
che prima erano destinate ad un singolo core. Avendo a disposizione un numero
maggiore di core, il sistema operativo può gestire in modo molto più �essibile e
veloce l'esecuzione di tutte le istruzioni, mappando i vari thread software su core
di�erenti. In questo modo i programmi scritti per essere eseguiti su core paralleli
bene�ciano di un aumento complessivo della velocità di esecuzione, al costo di una
maggiore complessità hardware. I core infatti sono singole CPU duplicate sullo stesso
chip, le quali però condividono alcune componenti del processore: ad esempio ogni
core possiede una cache L1 dedicata, mentre cache di più alto livello possono essere
condivise tra i core, con relativi metodi di comunicazione tra core per garantire la
cache coherence.
Le architetture multicore sono state anche adottate sui sistemi multiprocessore,
ottenendo quindi macchine che hanno più processori, ognuno dei quali contenente
più core �sici (Figura 1.4).
1.1.3 Pipeline e Instruction Level Parallelism (ILP)
Gli stadi dell'esecuzione di una istruzione sono generalmente cinque: fetch del-
l'istruzione (IF), decode dell'istruzione e lettura dei registri (ID), esecuzione dell'i-
struzione (EX), accesso in memoria (MEM) e scrittura nei registri (WB). Un core
6
1.1. Tecnologie dei moderni microprocessori
Figura 1.4: Multiprocessore con quattro core. L'immagine è ricavata da [12].
Figura 1.5: Esecuzione tradizionale delle istruzioni. L'immagine è ricavata da [42].
di un processore tradizionale eseguiva le istruzioni in modo sequenziale, ovvero la
singola istruzione passava attraverso tutti gli stadi in modo esclusivo. Una seconda
istruzione poteva entrare nel core solamente al termine dell'esecuzione della prima
istruzione (Figura 1.5). Ad ogni colpo di clock il processore procede ad elaborare i
dati dell'istruzione nello stadio attuale, impiegando così 5 cicli di clock per terminare
l'elaborazione dell'istruzione.
Per poter eseguire più istruzioni parallelamente si è quindi sviluppata la cosid-
detta pipeline, che permette di sfruttare il concetto di Instruction Level Parallelism
(ILP). La pipeline è come una catena di montaggio composta da diverse unità funzio-
nali, ognuna delle quali svolge una particolare attività nell'esecuzione dell'istruzione.
La pipeline segue lo schema tradizionale degli stadi di esecuzione di una istruzione,
con la di�erenza che può fare il fetch dell'istruzione successiva nel ciclo di clock im-
mediatamente seguente a quello in cui si è eseguito il fetch della prima istruzione.
La pipeline ha una fase di riempimento, in cui man mano tutti gli stadi vengono
occupati da una istruzione, a seguito del quale riesce a concludere l'esecuzione di
una istruzione ad ogni ciclo di clock (Figura 1.6). L'introduzione della pipeline ha
portato anche alla nascita di con�itti (hazards), dovuti all'esecuzione parallela del-
7
1.1. Tecnologie dei moderni microprocessori
Figura 1.6: Pipeline a 5 stadi. L'immagine è ricavata da [42].
le istruzioni. Questi con�itti rientrano nelle seguenti categorie: Structural Hazards,
Data Hazards e Control Hazards. Per ciascuno di questi problemi sono state studiate
delle tecniche che permettono di evitarli, benchè ciò comporti un rallentamento nella
pipeline. Solitamente viene detto che vi sono delle �bolle� nella pipeline, ovvero
stadi vuoti in cui non è presente alcuna istruzione in esecuzione. Questo comporta
delle degradazioni nelle prestazioni di esecuzione, poichè non si riesce a raggiungere
il rate ideale di Clock Per Instruction (CPI) pari ad 1.
Per migliorare ancora di più la pipeline si è permesso alle istruzioni di essere ese-
guite in un ordine diverso rispetto a quello con cui sono state fetchate. L'esecuzione
out-of-order avviene tramite tecniche di Dynamic Scheduling (come lo Scoreboard o
il Tomasulo Algorithm) o di Static Scheduling (processori VLIW ). Il risultato di una
istruzione viene salvato temporaneamente ed ha e�etto sullo stato architetturale del-
la macchina solo quando le istruzioni precedenti sono state correttamente eseguite
(ad esempio, dopo aver risolto le dipendenze da altre istruzioni o da dati, oppure
dopo aver eseguito il branch corretto di un salto condizionale). In questo modo si
aumenta l'utilizzo parallelo delle unità funzionali nella pipeline, in modo da sfrut-
tare la sovrapposizione di esecuzione tra istruzioni scorrelate (in assenza quindi di
hazards tra esse).
1.1.4 Processori superscalari
Per parallelizzare ulteriormente l'esecuzione di più istruzioni nella pipeline si
sono sviluppati i processori superscalari. Essi sono caratterizzati dal fatto che ad
ogni ciclo di clock immettono nella pipeline un numero maggiore di istruzioni (issue
di 2, 4 o 6 istruzioni alla volta, Figura 1.7). In questo modo ad ogni ciclo di clock
vengono completate idealmente 2, 4 o 6 istruzioni in un solo colpo, a patto che
non vi siano con�itti. Capire quali istruzioni accoppiare in modo da essere eseguite
contemporaneamente è la parte più impegnativa per lo scheduler, che deve evitare
di fare l'issue di istruzioni con dipendenze.
8
1.1. Tecnologie dei moderni microprocessori
Figura 1.7: Pipeline superscalare 5 stadi, 2-issue. L'immagine è ricavata da [42].
1.1.5 Simultaneous multithreading (SMT)
Per superare i limiti delle tecnologie che sfruttavano esclusivamente l'Instruction
Level Parallelism (ILP) si è deciso di applicare il concetto di thread software all'in-
terno delle architetture dei processori. Dal Thread Level Parallelism (TLP) quindi è
nata la tecnologia chiamata multithreading, che consiste nel fatto di poter eseguire
in modo concorrente un numero elevato di processi o thread software sullo stesso
core. Il multithreading ha come scopo quello di far lavorare le unità funzionali del-
la pipeline anche se il thread corrente è in uno stato di stallo (dovuto ad esempio
all'attesa di risorse o a causa di branch misprediction). Succede infatti molto fre-
quentemente che un processo sia in attesa di ricevere dati dalla memoria principale
o da periferiche esterne: questa attesa blocca il processore (le cosiddette �bolle�
nella pipeline), che non esegue quindi altro lavoro utile, perdendo tempo prezioso.
Con il multithreading invece il processore è in grado di eseguire istruzioni di altri
thread mentre quello attuale è bloccato. Tra i thread in esecuzione devono quindi
avvenire dei veloci cambi di contesto (context switch) controllati dall'hardware, il che
si traduce in un aumento di componenti per poter memorizzare gli stati dei thread
(vengono aggiunti più Register Files e Program Counter per ogni thread).
Il multithreading porta dei vantaggi soprattutto quando vi è un thread che fa
molti miss dalla cache, infatti con il multithreading il secondo thread può comun-
que essere eseguito e va ad occupare le risorse che altrimenti sarebbero inutilizzate.
Nel caso in cui un thread richieda esclusivamente capacità elaborativa dell proces-
sore (CPU intensive), il multithreading non porta e�ettivi bene�ci in quanto quel
thread non si troverà ad essere in uno stato di blocco e non verrà alternato con un
9
1.1. Tecnologie dei moderni microprocessori
Figura 1.8: Varie implementazioni del multithreading. L'immagine è ricavata da [36].
secondo thread. Tra gli svantaggi del multithreading troviamo anche una maggiore
interferenza nella condivisione delle risorse hardware tra i thread. In questo caso il
tempo di esecuzione dei thread potrebbe addirittura avere dei peggioramenti e quindi
non bene�ciare del multithreading. Infatti il multithreading non è una tecnologia
che raddoppia la componentistica hardware di un core (altrimenti avremmo due co-
re e�ettivi) ma è una tecnologia che riesce a far eseguire al medesimo core due o
più thread intervallando le istruzioni ed eseguendole solo se esse lavorano su unità
funzionali di�erenti.
Tra le varie implementazioni del multithreading (Figura 1.8) la versione più avan-
zata viene chiamata Simultaneous multithreading (SMT) e combina sia il concetto
di TLP sia il concetto di ILP sui moderni processori superscalari. L'SMT nasce
dall'idea che un core abbia un elevato numero di unità funzionali che un singolo
thread non utilizzerà mai. Alcune di esse quindi rimarranno inutilizzate e l'SMT si
preoccuperà di fare l'issue di istruzioni da più thread (Figura 1.9) che permettano un
uso maggiore del core. Il Dynamic Scheduler si preoccupa di risolvere le dipendenze
multiple tra le istruzioni (fattore che limita il numero di istruzioni di cui si può fa-
re l'issue), mentre tecniche di register renaming permettono di sapere quali registri
appartengono a determinati thread in modo da evitare di accedere a registri di altri
thread.
Nella maggior parte dei casi l'SMT (e il multithreading in generale) è una tec-
nologia che permette di �nascondere� il fatto che alcuni processi abbiano una lunga
latenza, permette di aumentare l'e�cienza del processore e generalmente riduce i
tempi di esecuzione più di quanto aumenti il consumo medio di energia. Una ovvia
controindicazione dell'SMT è che avendo più thread eseguiti parallelamente il tem-
po di esecuzione di ciascuno di essi viene complessivamente penalizzato, benchè sia
preferibile rispetto a una esecuzione senza multithreading nella maggior parte dei
10
1.1. Tecnologie dei moderni microprocessori
Figura 1.9: Scheduling di cinque thread in SMT. L'immagine è ricavata da [36].
casi.
Ovviamente l'SMT è una tecnologia che può essere adottata su sistemi multipro-
cessore e multicore, essendo una caratteristica peculiare dei core di cui il sistema è
composto (esempio in Figura 1.10).
1.1.5.1 Intel Hyper-Threading Technology
L'Hyper-Threading Technology (HT) è l'implementazione di Intel dell'SMT su
processori x86 atta a migliorare il parallelismo dei task eseguiti contemporaneamente
(si veda [6]). Entra nel mercato nel 2002 su processori Xeon e sui Pentium 4 ed è
tutt'oggi utilizzata sui nuovi processori Atom e della serie Core i. L'implementazione
dell'HT prevede che un core �sico venga visto dal sistema operativo come se sulla
macchina vi fossero in realtà due core �sici. Questi due core vengono detti core logici
in quanto essi non esistono veramente, ma rappresentano i due thread che il core
�sico può gestire, ognuno con il suo stato architetturale (Figura 1.11) . Per gestire lo
stato architetturale del secondo thread, Intel ha duplicato solo alcune parti del core
�sico, mentre le rimanenti unità funzionali vengono condivise tra i due thread (tra
le quali in particolare le execution units). Complessivamente l'aumento delle risorse
hardware per gestire l'HT incide per meno del 5% dell'area del die del processore.
In particolare Intel de�nisce quattro policies per gestire le risorse all'interno di un
core, in Tabella 1.1 è indicato come vengono gestite alcune risorse di esempio.
Il sistema operativo può quindi schedulare due processi sui due core logici ed essi
vengono gestiti dall'hardware come due thread sul singolo core �sico. Se le risorse di
un processo non sono attualmente disponibili (ad esempio, è in attesa di dati dalla
memoria principale o da periferiche) allora un'altro processo che ha risorse disponibili
può continuare la sua esecuzione, riuscendo così ad evitare uno stallo del core. Il
11
1.1. Tecnologie dei moderni microprocessori
Figura 1.10: Processore dual core con SMT. I thread utilizzano diverse unitàfunzionali. L'immagine è ricavata da [36].
Figura 1.11: Di�erenze nell'architettura di un processore con e senza l'Intel Hyper-Threading Technology. L'immagine è ricavata da [6].
12
1.1. Tecnologie dei moderni microprocessori
Tabella 1.1: Intel implementation policies: modalità di gestione di alcune risorse inuna architettura con HT. La tabella è ricavata da [6].
Policy Descrizione Risorsa
Replicated Logica duplicata per threadRegister StateRenamed RSB
Large Page ITLB
Partitioned Allocata staticamente tra i thread
Load Bu�erStore Bu�er
Reorder Bu�erSmall Page ITLB
Competively Shared Dipendente dal comportamento dinamico del thread
Reservation StationCaches
Data TLB2nd level TLB
Unaware Nessun impatto Execution units
valore massimo di istruzioni ritirabili per clock (IPC) è pari a 2 per i processori della
famiglia Atom, mentre è pari a 4 per tutti gli altri processori supportati.
Intel ha dichiarato che le performance del sistema possono aumentare �no al 30%
utilizzando l'HT, ma successivamente ha aggiunto che i miglioramenti in prestazioni
dipendono dal tipo di applicazione che è in esecuzione sulla macchina. Vi sono infatti
applicazioni che possono avvantaggiarsi dell'HT se sono programmate in modo da
usare multipli thread, mentre altre ottengono risultati peggiori in termini di latenza
di processamento (applicazioni che non scalano adeguatamente, che hanno thread
non bilanciati oppure che presentano bottlenecks dovuti al parallelismo).
1.1.6 Dynamic frequency and voltage scaling
Nei recenti processori è stata introdotta la tecnologia di Dynamic frequency and
voltage scaling che permette al sistema di variare in tempo reale la frequenza (e il
voltaggio) di funzionamento del processore. Questa tecnologia è utilizzata in diverse
situazioni, ad esempio nei casi in cui si voglia adottare una politica di power saving
per ridurre i consumi di energia elettrica. Infatti questa tecnologia è stata introdotta
per aumentare anche la durata delle batterie di computer portatili, per diminuire
il calore prodotto e per ridurre il lavoro dei dissipatori a ventola. La variazione di
frequenza inoltre è utile quando un sistema non deve eseguire operazioni: è giusto che
lo si porti in uno stato in cui la frequenza di funzionamento sia la minore possibile
per non avere un consumo inutile di energia.
Quando si studiano le performance di un computer bisogna tenere in considerazio-
ne che la frequenza di funzionamento può variare: infatti questo ha delle implicazioni
sul numero di istruzioni che il processore può eseguire in ogni ciclo di clock. Un pro-
cessore a bassa frequenza esegue un numero inferiore di istruzioni rispetto al caso in
cui la sua frequenza fosse �ssata al massimo consentito.
13
1.1. Tecnologie dei moderni microprocessori
1.1.6.1 Processor states
Nello standard Advanced Con�guration and Power Interface (ACPI) sono stati
de�niti gli stati di funzionamento che ogni processore deve implementare. Questi
stati, chiamati C-states, sono indicati dalle sigle C0...C3 e segnalano qual'è lo stato
operativo del processore. Il sistema operativo si occupa di richiedere lo stato del
processore a seconda del lavoro che deve svolgere. Quando il processore deve eseguire
l'elaborazione di istruzioni viene generalmente richiesto lo stato C0, che indica lo
stato di attività del processore. Gli stati successivi C1, C2 e C3 indicano un livello
di inattività del processore via via più profondo (da Halt a Sleep). Questi livelli
sono caratterizzati da un numero sempre maggiore di componenti del processore
disattivate. I produttori di alcuni processori possono anche aggiungere stati idle
successivi per avere speci�che funzionalità avanzate.
1.1.6.2 Performance states
Ortogonali ai processor states, sono stati de�niti i performance states (P-states),
indicati dalle sigle P0, P1, ..., Pn che indicano lo stato di performance energetica da
assegnare al processore mentre si trova nello stato di lavoro C0. Lo stato P0 è lo stato
più performante, ovvero lo stato in cui la frequenza e la potenza del processore sono
al massimo. Gli stati successivi diminuiscono gradualmente voltaggio e frequenza
del processore, in modo da avere stati meno performanti ma che hanno un consumo
energetico inferiore. In questo modo si può far scegliere al sistema operativo quanta
energia far utilizzare al processore in un dato momento.
I P-states sono implementati in modo indipendente dai vari produttori di hard-
ware: Intel ha de�nito il suo Enhanced Intel SpeedStep Technology (EIST) che per-
mette di scalare frequenza e voltaggio del processore (quindi cambiare P-state) per
soddisfare le necessità energetiche delle operazioni che devono essere e�ettuate in quel
momento dal processore. L'EIST viene quindi per lo più utilizzata come tecnologia
di power saving.
Su Linux è stato implementato l'Intel P-State driver (si veda [24]), che è l'in-
terfaccia Intel per controllare i P-state nelle famiglie di processori da Sandy Bridge
in poi. Questo driver è andato a sostituire il classico ACPI CPUfreq e ha portato
diversi cambiamenti nella gestione del power managment. In particolare i governor
sono stati ridotti esclusivamente a powersave e performance, introducendo anche in
questi governor delle modi�che rispetto al driver precedente. Il driver Intel utilizza
dei �le di con�gurazione che è possibile modi�care per ottenere il P-state desiderato.
In particolare si segnalano:
� /sys/devices/system/cpu/intel_pstate/max_perf_pct: limita il massimo P-
state che può essere richiesto dal driver. Viene indicato da una percentuale sul
livello di performance disponibile.
14
1.1. Tecnologie dei moderni microprocessori
Figura 1.12: Frequenze massime variabili in base al numero di core attivi grazie alTurbo Boost di Intel. L'immagine è ricavata da [17].
� /sys/devices/system/cpu/intel_pstate/min_perf_pct: limita il minimo P-
state che può essere richiesto dal driver. Viene indicato da una percentuale
sul livello massimo di performance senza turbo.
� /sys/devices/system/cpu/intel_pstate/no_turbo: impone al driver di
scegliere P-state al di sotto del range di frequenze del turbo.
Bisogna evidenziare che tali con�gurazioni vengono prese dal driver come delle sem-
plici indicazioni su come scegliere il P-state desiderato e quindi nei processori Intel
Core non è possibile forzare una singola frequenza esatta. La frequenza del proces-
sore infatti è controllata dal processore stesso, che può variarla a proprio piacere a
seconda della necessità, ovviamente cercando di rispettare le indicazioni richieste dal
driver.
1.1.6.3 Intel Turbo Boost
Diametralmente opposte alle tecnologie di power saving che limitano la frequenza
di lavoro del processore si hanno le tecnologie di performance boosting, ovvero quelle
tecnologie che permettono al processore di essere più performante ed eseguire più
lavoro al prezzo di un consumo energetico maggiore. Si entra quindi nel campo
del dynamic overclocking, che permette di aumentare dinamicamente la frequenza di
clock, spingendola oltre alla frequenza base del processore.
Intel ha implementato la propria tecnologia di boosting col nome di Turbo Boost
(TB), la cui versione attuale è la 2.0 (si veda [10]). Nelle speci�che tecniche dei
processori Intel viene solitamente indicata sia la Processor Base Frequency, che è
la frequenza nominale con TB non attivo, sia la Max Turbo Frequency, che è la
frequenza massima a cui può arrivare il processore sfruttando il TB (con un solo core
attivo). Se più core sono attivi contemporaneamente, la Max Turbo Frequency avrà
un valore via via inferiore (Figura 1.12).
15
1.1. Tecnologie dei moderni microprocessori
Il TB viene attivato quando il sistema operativo richiede lo stato di performance
più elevato P0. La frequenza viene incrementata a step �ssi (133MHz per processori
Nehalem, 100MHz per processori Sandy Bridge, Ivy Bridge e Haswell) �no a raggiun-
gere il livello richiesto. La frequenza ovviamente sarà limitata superiormente dalla
Max Turbo Frequency in relazione al numero di core attivi. Se la temperatura del
processore dovesse andare oltre ai limiti di sicurezza �ssati, allora il TB viene disatti-
vato e la frequenza viene decrementata �no a quando si ristabilisce una temperatura
ottimale.
1.1.7 Model-speci�c registers
ConModel-speci�c register (MSR) si indica un registro che fa parte del set di regi-
stri di controllo presente nelle architetture x86. Un MSR è �nalizzato a memorizzare
dati relativi al debugging e all'esecuzione dei programmi, ma anche al monitoring
delle performance del computer, oltre che a gestire numerosi parametri di interesse
per il sistema operativo. Questi registri possono essere scritti e letti con le istruzioni
privilegiate assembly WRMSR e RDMSR.
Alcuni di questi registri sono stati ritenuti da Intel fondamentali per ogni archi-
tettura da loro sviluppata e quindi sono stati inclusi in tutte le successive famiglie di
processori: vengono chiamati architectural MSRs e il loro nome storicamente inizia
con �IA32_�. Intel garantisce che questi registri verranno mantenuti inalterati da
un'architettura alla successiva. Tra questi MSR ne troviamo alcuni che contengono
informazioni sul tipo di processore e sulle sue caratteristiche, che possono essere ri-
scritti per alterare il funzionamento standard del processore. Esistono anche registri
che possono essere programmati per registrare particolari eventi, come ad esempio
gli MSR dedicati alle performance del sistema.
Oltre ai registri architetturali, Intel de�nisce per ogni nuova famiglia di processore
dei non architectural MSR, ovvero dei registri speci�ci per quella famiglia (benchè
a volte possano essere riportati in famiglie successive). Questi registri ampliano
il livello di con�gurabilità delle caratteristiche del processore a seconda delle sue
funzionalità. Nei Software Developer's Manuals (si veda [9]) vengono elencati tutti
gli MSR architetturali e non architetturali, per ogni famiglia di processore.
1.1.7.1 Hardware performance counters
Un set di MSR è stato dedicato da Intel alla misurazione delle performance
dell'hardware e pertanto questi registri sono stati chiamati Hardware performance
counters (PCs). Intel ha dato un nome del tipo IA32_PERFEVTSELx ad alcuni di
questi registri registri, stando ad indicare che questi registri possono essere program-
mati per monitorare particolari eventi di interesse (alcuni esempi sono i miss durante
gli accessi alle cache, i cicli di clock eseguiti, l'utilizzo del bus di sistema, le istruzioni
16
1.1. Tecnologie dei moderni microprocessori
Tabella 1.2: Intel Pre-de�ned Architectural Performance Events con relativi selettorie umask. La tabella è ricavata da [9].
Event Name UMask Event Select
UnHalted Core Cycles 00H 3CHInstruction Retired 00H C0H
UnHalted Reference Cycles 01H 3CHLLC Reference 4FH 2EHLLC Misses 41H 2EH
Branch Instruction Retired 00H C4HBranch Misses Retired 00H C5H
ritirate dal processore, ecc...). Intel distingue i performance events in architetturali
(si comportano in modo consistente tra architetture successive) e non architetturali
(speci�ci per la tale architettura). Il risultato del monitoraggio di un evento viene
scritto in un registro dal nome IA32_PMCx, accoppiato al relativo MSR dell'evento.
La gestione dei PC viene delegata alle Performance Monitoring Units (PMUs) dislo-
cate sui core di Intel, le quali registrano sia gli eventi che accadono all'interno del core
sia quelli che accadono al suo esterno (core and uncore PMUs). Questo permette di
ottenere, oltre alle metriche tradizionali all'interno del core, anche nuove metriche di
componenti esterne al core, che altrimenti non sono mai monitorate. Alcuni esempi
delle metriche core e uncore sono:
� Core: istruzioni ritirate, cicli di clock trascorsi, frequenza del core, hit e miss
di cache L2 e L3
� Uncore: byte letti dai memory controllers, byte scritti nei memory con-
trollers, tra�co dei dati trasferiti dai link inter-processori (Intel QuickPath
Interconnect).
Intel ha de�nito una serie di eventi architetturali standard visibili in Tabella 1.2. Tra
questi eventi si evidenziano quelli che saranno di particolare interesse per il modello
che si andrà a sviluppare successivamente:
� UnHalted Core Cycles: questo evento conteggia il numero di cicli di clock in
cui il core è nello stato attivo (non è halted), ovvero quando si trova nello stato
C0. Il PC di questo evento conteggia i cicli di clock attraverso la variazione
di performance states, i quali variano la frequenza di clock del processore.
Questo implica che il contatore venga incrementato più o meno frequentemente
all'aumentare o al diminuire della frequenza di clock, in quanto seguono il suo
andamento.
� Instructions Retired: questo evento conteggia il numero di istruzioni che
vengono ritirate dal core. Un'istruzione viene ritirata quando viene eseguita
17
1.2. Modelli e metriche di performance tradizionali
Tabella 1.3: Intel Pre-de�ned Fixed-Function PC con relativi eventi e indirizzi deiPC. La tabella è ricavata da [9].
Event Name Fixed-Function PC PC Address
INST_RETIRED.ANY MSR_PERF_FIXED_CTR0/IA32_FIXED_CTR0 309HCPU_CLK_UNHALTED.CORE MSR_PERF_FIXED_CTR1/IA32_FIXED_CTR1 30AHCPU_CLK_UNHALTED.REF MSR_PERF_FIXED_CTR2/IA32_FIXED_CTR2 30BH
dalla pipeline in modalità Out-of-order, esce dalla Retirement Unit e il suo
risultato viene applicato allo stato architetturale come se fosse stata eseguita
In-order. Per istruzioni composte da più micro-ops, il PC viene incrementato
solo quando l'ultima micro-op viene ritirata.
� UnHalted Reference Cycles: questo evento conteggia il numero di cicli di
clock di riferimento (reference clock cycles) mentre il core è nello stato attivo
(non è halted), ovvero quando si trova nello stato C0. Il reference clock opera
a una frequenza �ssa (la cosiddetta TSC Reference Frequency) che non risente
dei cambi di frequenza dovuti alle transizioni tra i vari performance states.
Questo implica che il contatore venga incrementato in modo costante con la
frequenza del reference clock.
I processori Intel basati su architettura Intel Core possiedono tre PC denominati �-
xed function. Ognuno di questi tre registri è nativamente dedicato al conteggio degli
speci�ci pre-de�ned architectural event (Tabella 1.3), benchè possano essere ripro-
grammati per conteggiare un evento qualsiasi tra quelli pre-de�ned. Oltre ai tre �xed
function PC, le architetture Intel Core possiedono dei registri general purpose che
possono essere programmati per conteggiare i PC degli eventi di interesse. Tutti gli
eventi disponibili sulle varie architetture sono documentati nei Software Developer's
Manuals (si veda [9]). La famiglia Nehalem possiede quattro registri general purpose
per core (IA32_PMC0, IA32_PMC1, IA32_PMC2, IA32_PMC3). Dalla famiglia
Sandy Bridge in poi si hanno otto registri general purpose per core �sico. Nel caso in
cui l'Hyper-Threading sia attivo sul core, a ciascun thread logico vengono assegnati
quattro degli otto registri.
1.2 Modelli e metriche di performance tradizionali
1.2.1 Operational analysis
La teoria della operational analysis, insieme alla teoria delle queuing networks, è
stata applicata ai sistemi informatici �n dall'inizio dello studio delle loro performance
(si veda [14,23,26]). Le relazioni matematiche della operational analysis permettono
di calcolare e predire importanti indici di performance dei sistemi informatici. Il
sistema più semplice viene de�nito da una sola risorsa e la sua relativa coda (Figura
18
1.2. Modelli e metriche di performance tradizionali
Figura 1.13: Coda M/M/1. L'immagine è ricavata da [41].
1.13) ed è identi�cato dalla notazione M/M/1 (arrivi determinati da un processo di
Poisson, Service time con distribuzione esponenziale, un solo servitore).
Un sistema, composto da varie risorse, viene osservato per un intervallo di tempo
T. Durante tale periodo arrivano al sistema, e quindi alle sue risorse, un certo numero
di richieste (Arrivals). De�niamo Arrival rate la frequenza di arrivo di una richiesta
alla risorsa k-esima o al sistema (Formula 1.1).
λk =AkT
(1.1)
La metrica di utilizzo (Utilization) di una risorsa k viene de�nita come la quantità
di tempo in cui la risorsa osservata è occupata a svolgere lavoro utile (Busy time)
rispetto al tempo totale di osservazione del sistema (Formula 1.2). L'utilizzo non
può superare l'unità, in quanto la risorsa non può essere stata occupata un tempo
maggiore rispetto all'intervallo di osservazione.
Uk =BkT
≤ 1 (1.2)
Il Throughput viene de�nito come la quantità di lavoro svolta da una risorsa k
(ovvero il numero di richieste completate, Completions) nell'intervallo di osservazione
T (Formula 1.3).
Xk =CkT
(1.3)
Nel caso si consideri un sistema intero, si ha X = CT . Generalmente in un sistema
il throughput indica il numero di job che sono stati eseguiti per unità di tempo. Ad
esempio in un sistema transazionale il throughput indica il numero di richieste per
secondo che il sistema ha servito.
Con visita (Visit) si de�nisce il numero di volte che una risorsa k viene visitata
da un job durante l'osservazione del sistema (Formula 1.4). Il numero di visite quindi
è il rapporto tra le richieste completate dalla risorsa rispetto a quelle completate da
tutto il sistema.
Vk =CkC
(1.4)
La Forced Flow Law (Formula 1.5) è una legge ottenuta algebricamente dalle rela-
zioni precedenti. Essa lega il throughput e le visite di una risorsa k con il throughput
19
1.2. Modelli e metriche di performance tradizionali
dell'intero sistema.
Xk = VkX (1.5)
Il Service time (Formula 1.6) e il Service Demand (Formula 1.7) di una risorsa k
sono due metriche che indicano il tempo di servizio medio per richiesta completata
e il tempo medio di servizio per tutte le richieste del sistema. Osservando una
risorsa per un intervallo T, il Service time è de�nito come il rapporto tra il Busy
time della risorsa con il numero di richieste completate dalla risorsa nell'intervallo.
Il Service Demand è de�nito come il rapporto tra il Busy time della risorsa con il
numero di richieste completate dall'intero sistema nell'intervallo di osservazione. Con
le relazioni precedenti si ottengono algebricamente delle de�nizioni equivalenti.
Sk =BkCk
=UkT
Ck(1.6)
Dk =BkC
=UkT
C= VkSk (1.7)
Combinando algebricamente le relazioni precedenti si ottiene la Utilization Law
(Formula 1.8), che ride�nisce la metrica di utilizzo di una risorsa.
Uk = XkSk = XDk (1.8)
De�niamo tempo medio di risposta della risorsa k (Response time, Formula 1.9)
la somma del suo Service time con il tempo medio che una richiesta passa nella coda
della risorsa (Queue time).
Rk = Sk +Qk (1.9)
Il tempo medio di risposta dell'intero sistema è quindi calcolato come la somma-
toria su tutte le risorse del prodotto tra il Response time della risorsa con il numero
di visite alla risorsa (Formula 1.10).
R =∑k
RkVk (1.10)
Per un sistema transazionale usualmente il tempo di risposta indica quanto tempo è
trascorso dal momento in cui l'utente ha inviato la sua richiesta al momento in cui
ha ricevuto la risposta dal sistema.
La Utilization Law è un caso particolare della Little's Law (Formula 1.11), in
cui si a�erma che il numero medio di richieste presenti nel sistema (N) è pari al
throughput del sistema per il tempo medio di risposta del sistema.
N = XR (1.11)
Supponendo che il sistema sia acceduto da utenti che mediamente hanno un pe-
20
1.2. Modelli e metriche di performance tradizionali
riodo di attesa tra la ricezione di una risposta dal sistema e l'invio di quella successiva
pari a Z (Think time), possiamo introdurre la Response Time Law (Formula 1.12).
R =N
X− Z (1.12)
In�ne si de�nisce Output rate (Formula 1.13) la frequenza di completamento di
una richiesta da parte di una risorsa o dell'intero sistema.
µk =1
Sk(1.13)
Nel caso di modelli aperti con una coda M/M/1 che rispettano la Steady State
Condition (condizione di equilibrio del sistema per cui λ ≡ µ ≡ X) si hanno le
seguenti ulteriori relazioni per la singola risorsa:
U =λ
µ= λS < 1 (1.14)
N =U
1− U(1.15)
R =
D1−U se V>1
S1−U se V=1
(1.16)
Nel caso di una coda M/M/2, ovvero un sistema con una coda che ha due servitori,
si hanno le seguenti relazioni:
U =λ
2µ=λ
2S < 1 (1.17)
N =2U
1− U2(1.18)
R =
D1−U2 se V>1
S1−U2 se V=1
(1.19)
Questi due modelli possono essere usati per rappresentare rispettivamente un pro-
cessore con un core e un processore con due core. In [4] è stato evidenziato come
una coda M/M/2 in realtà non riesca a modellare correttamente il comportamento
di un processore dual core. Questo succede perchè vi sono limiti dovuti alla dimen-
sione delle cache, alla banda condivisa e a lock sulla memoria che diminuiscono il
parallelismo dei due core. Viene proposto quindi un modello alternativo indicato con
M/M/α in cui si ha 1 ≤ α ≤ 2. La coda lavora a velocità µ quando vi è un solo job
nel sistema, mentre quando vi è più di un job opera a velocità αµ. Quando α = 1
il sistema opera come una coda M/M/1, se α = 2 si ha una coda M/M/2, mentre
nei rimanenti casi si hanno delle modellizazioni intermedie. Si ottengono quindi le
21
1.2. Modelli e metriche di performance tradizionali
seguenti relazioni:
U =λ
αµ=λ
αS (1.20)
R =
D1+(α−2)U+(1−α)U2 se V>1
S1+(α−2)U+(1−α)U2 se V=1
(1.21)
1.2.2 Modello tradizionale per la stima dell'utilizzo
Le leggi dell'operation analysis vengono applicate quotidianamente nella pratica
industriale per la misurazione, il dimensionamento e la stima di un sistema infor-
matico. Quando si svolge uno studio di piani�cazione della capacità di un sistema
(capacity planning) viene innanzitutto analizzato il sistema in oggetto raccogliendo
quanti più dati possibili sulle sue caratteristiche hardware e software. In particolare
si identi�cano:
� i modelli delle varie componenti hardware con le relative prestazioni dichiarate
(frequenze massime e minime, disponibilità di storage, dimensioni della memo-
ria principale e delle cache, banda di trasferimento, ecc...) e le tecnologie che il
sistema può sfruttare (numero di thread, power saving, performance boosting,
ecc...)
� il software che viene eseguito sul sistema, con particolare attenzione all'appli-
cativo che il sistema deve eseguire quando arrivano delle richieste (con quali
tecnologie è sviluppato, di quali e quante risorse necessita, ecc...)
In seguito viene monitorato il sistema durante il suo workload quotidiano, tenendo
traccia in �le di log di quanto vengano utilizzate le risorse che lo compongono. Ana-
lizzando i �le di log si riesce a comprendere il comportamento del sistema quando
elabora il carico, ovvero quanto le sue risorse siano utilizzate e che capacità residua
sia disponibile, anche nel caso di �uttuazioni del carico (situazioni in cui il sistema è
idle e situazioni in cui il carico cresce e il sistema diventa eventualmente saturo). Si
comprende quindi quali siano le prestazioni che l'hardware riesce e�ettivamente ad
o�rire a seconda del numero di richieste a cui il sistema riesce a rispondere.
Supponiamo di avere un sistema che abbia un carico di lavoro basso (utilizzo
delle risorse pari al 30-40%). Si vuole ora stimare l'utilizzo di una risorsa al crescere
del throughput del sistema, ovvero si vuole studiare come varia l'utilizzo di quella
risorsa se al sistema viene somministrata una quantità di lavoro maggiore. Prendia-
mo in considerazione, ad esempio, il processore presente nel sistema in studio. Dai
�le di log dobbiamo estrarre coppie di valori che legano l'utilizzo del processore al
throughput del sistema. Applicando l'Utilization Law (Formula 1.8) come regressio-
ne lineare dei dati raccolti, riusciamo a stimare il Service Demand del processore.
22
1.2. Modelli e metriche di performance tradizionali
0 2 4 6 8 10 120
10
20
30
40
50
60
70
80
90
100
Utilization Law M/M/1
Misurato
Previsione
Effettivo
Throughput (req/s)
Utiliz
zo
Figura 1.14: Previsione dell'utilizzo del sistema M/M/1 di esempio. I dati e�ettiviad alto carico confermano la previsione.
Sapendo che l'utilizzo cresce linearmente con il throughput a Service Demand co-
stante, possiamo trovare il punto che corrisponde all'utilizzo del processore pari al
100%. Questo punto ci indica il throughput massimo che il sistema può teoricamente
elaborare. Per fare un esempio si suppone di avere un sistema M/M/1 ideale in cui
sono stati misurati dei dati durante un carico di lavoro basso (i dati in blu in Figura
1.14). Questi dati sono stati utilizzati per e�ettuare la regressione lineare che preve-
de l'andamento del sistema. I dati in arancione sono stati successivamente misurati
quando è stato somministrato un carico maggiore al sistema. Si evidenzia come tali
dati siano esattamente aderenti alla previsione che è stata fatta a basso carico (il
coe�ciente di determinazione R2 della regressione lineare risulta essere pari a uno).
Per trovare però il valore massimo di throughput in modo che il Response time
abbia dei valori accettabili che rispettano vincoli di Quality of Service (QoS), dob-
biamo considerare il gra�co in Figura 1.15. Esso mostra come il tempo di risposta
abbia una crescita a �mazza da hockey� quando l'utilizzo del sistema aumenta (in
concomitanza con il throughput). Se si �ssasse una soglia massima di accettabilità
del tempo di risposta di 0,5 secondi, allora l'utilizzo di sistema sarebbe pari all'80%,
che corrisponde ad un throughput di 8 req/s. Il valore del throughput è quindi indice
di quanto carico si posso ancora somministrare al sistema �no al riempimento dello
spazio libero ancora utilizzabile (il cosiddetto �headroom�).
La procedura descritta è una pratica industriale assodata per la stima delle
performance di sistemi tradizionali, come ad esempio i server di un datacenter.
23
1.3. Tools di monitoraggio e reportistica
0 10 20 30 40 50 60 70 80 90 1000
0,5
1
1,5
2
2,5
3
3,5
4
4,5
Response Time M/M/1
Misurato
Effettivo
Utilizzo
Tem
po d
i ri
spos
ta (
s)
Figura 1.15: Tempi di risposta del sistema M/M/1 di esempio. Seguono l'andamentoa mazza da hockey.
1.3 Tools di monitoraggio e reportistica
In questa sezione verranno descritti alcuni tool utilizzati in ambito Linux per
monitorare lo stato delle risorse �siche di una macchina così come sono viste dal
sistema operativo.
1.3.1 Top
Top (Figura 1.16) è un tool che fornisce una visione in tempo reale del sistema nel
suo complesso: infatti top riporta sia le statistiche del sistema (utilizzo dei processori,
della memoria, load medio, ecc...) sia la lista dei processi o dei thread che sono
gestiti dal kernel (mostrando la relativa quantità di risorse usate). Permette inoltre
di manipolare i processi, come ad esempio imporre la loro terminazione o cambiarne
il valore di nice (e quindi la priorità nello scheduler).
Ci concentriamo ora sugli indici di utilizzo dei processori. L'utilizzo di un pro-
cessore (CPU time) viene de�nito come la percentuale di tempo in cui il processore
è stato attivo (operante nello stato C0) durante l'intervallo di osservazione (general-
mente il tempo di aggiornamento del tool, che è personalizzabile). Tale de�nizione
corrisponde alla Formula 1.2. Se il sistema ha più core �sici e logici, il sistema opera-
tivo li tratta tutti come e�ettivi core �sici e pertanto top calcola l'utilizzo di ognuno.
Nel caso si voglia avere l'utilizzo aggregato su tutto il sistema, allora top calcola la
24
1.3. Tools di monitoraggio e reportistica
Figura 1.16: Esempio di schermata del tool Top.
25
1.3. Tools di monitoraggio e reportistica
media dell'utilizzo di tutti i core. Ad esempio se si hanno quattro core e due di essi
sono utilizzati al 100%, top mostrerà un utilizzo complessivo del 50%.
Le percentuali di utilizzo vengono inoltre suddivise a seconda di quale sia l'utente
che ha lanciato il processo:
� user (us): percentuale di CPU time occupata da processi lanciati da utenti
(senza priorità nice)
� system (sy): percentuale di CPU time occupata da processi lanciati dal kernel
� nice (ni): percentuale di CPU time occupata da processi lanciati da utenti
(con priorità nice)
� IO-wait (wa): percentuale di CPU time occupata in cui la CPU è idle a causa
dell'attesa di richieste I/O
� idle (id): percentuale di CPU time in cui la CPU rimasta idle (senza richieste
I/O)
Un'altra metrica che top riporta è il load average del sistema. Il load average è de�-
nito come il numero medio dei processi che sono in uno stato runnable (in esecuzione
nel processore o che sono in attesa di essere eseguiti) o uninterruptable (in attesa
del completamento di operazioni di I/O). Un computer completamente idle ha load
average pari a zero, mentre non vi è limite al valore che il load average può assumere.
Viene indicato con una tripletta di valori, che stanno ad indicare rispettivamente il
load average dell'ultimo minuto, degli ultimi 5 minuti e degli ultimi 15 minuti.
Una versione di top più interattiva e di utilizzo sempli�cato è il tool htop.
1.3.2 Vmstat
Vmstat (Figura 1.17) è un tool che riporta varie statistiche del sistema, quali il
numero di processi, l'utilizzo della memoria (principale, cache, swap, ecc...), le trap
del sistema operativo, l'utilizzo dei dischi e dei processori. Le statistiche sono con-
teggiate su un periodo che viene impostato dall'utente. E' un tool molto comodo in
quanto presenta i dati in una visualizzazione compatta e di immediata comprensione.
1.3.3 Turbostat
Turbostat (Figura 1.18) è un tool che riporta diverse statistiche sui processori
del sistema. In particolare riporta la topologia, la frequenza, la temperatura, e il
consumo di potenza dei core, oltre ad ulteriori informazioni se sul sistema vi sono
gli hardware performance counters (l'utente può includere nella reportistica anche il
contenuto di speci�ci MSR). Le statistiche sono conteggiate sull'intervallo che viene
impostato dall'utente. Alcune metriche che si vogliono segnalare sono:
26
1.3. Tools di monitoraggio e reportistica
Figura 1.17: Esempio di schermata del tool Vmstat.
Figura 1.18: Esempio di schermata del tool Turbostat.
27
1.3. Tools di monitoraggio e reportistica
Figura 1.19: Esempio di schermata del tool Sar.
� Avg_MHz: numero di cicli eseguiti rispetto all'intervallo di misurazione,
ovvero la frequenza media del core durante l'intervallo
� %Busy: percentuale dell'intervallo di misurazione in cui il core ha ritirato
istruzioni, ovvero la percentuale di tempo in cui il core è stato nello stato C0
(sinonimo di utilizzo del core o CPU time)
� Bzy_MHz: frequenza media del core mentre si trovava nello stato C0, ovvero
la frequenza del core quando era in stato attivo, la cosiddetta Active Frequency
(AFREQ)
� TSC_MHz: frequenza media del TSC durante l'intervallo
� CPU%cX: percentuale di residenza del core nello stato di idle CX
1.3.4 Sar
Sar (Figura 1.19) è un tool molto potente e �essibile, che permette di fare mo-
nitoring e reporting delle informazioni sulle attività del sistema. Nella sua forma
più semplice permette di monitorare l'utilizzo dei processori dell'intero sistema, det-
tagliando le informazioni sulle varie percentuali di utilizzo come già descritto nella
Sezione 1.3.1. L'utente può impostare quante volte far monitorare a sar il sistema
e quanto a lungo far durare l'intervallo di misurazione. Sar può monitorare a tut-
to tondo ciò che accade sulla macchina: statistiche dell'I/O e dei trasferimenti dati,
creazione dei processi, i �le di paging, statistiche di rete (socket create, pacchetti tra-
smessi, interfacce di rete, ecc...), l'utilizzo dei processori, il load average di sistema,
l'utilizzo della memoria e molte altre statistiche. Queste statistiche possono essere
28
1.3. Tools di monitoraggio e reportistica
Figura 1.20: Esempio di schermata del tool Perf stat.
salvate in un �le binario e lette in un secondo momento con il tool stesso oppure
possono essere lette e manipolate con il tool sadf.
1.3.5 Perf
Perf (Figura 1.20) è un tool speci�co per l'analisi delle performance su Linux.
Esso si basa sugli hardware performance counters per analizzare le performance di
tutte le componenti del sistema, ma anche su tracepoint e software counters messi a
disposizione dal sistema operativo. Fornisce all'utente diversi comandi:
� Stat: lancia un comando e raccoglie i PC di interesse (secondo gli eventi
indicati) durante la sua esecuzione
� Top: raccoglie e mostra in tempo reale i PC di interesse (secondo gli eventi
indicati) di tutto il sistema
� Record: lancia un comando e raccoglie dentro al �le perf.data i PC di interesse
(secondo gli eventi indicati) durante la sua esecuzione
� Report: mostra i dati contenuti in un �le generato dal comando record
� List: mostra una lista di eventi che hanno un nome simbolico, questi eventi
possono essere usati come parametro negli altri comandi. Questa lista è un sot-
toinsieme degli eventi messi a disposizione dal processore, infatti sono eventi a
cui è stato associato un nome per facilitarne l'uso. Per una lista completa degli
eventi consultare gli Intel Software Developer's Manuals (si veda [9]). In alter-
nativa il tool ocperf all'interno della suite pmu-tools (si veda [25]) e il tool sho-
wevtinfo all'interno del pacchetto perfmon2 (si veda [31]) sono due programmi
che permettono di ottenere la lista degli eventi supportati dal processore.
29
1.3. Tools di monitoraggio e reportistica
Figura 1.21: Esempio di schermata del tool PCM.
Gli eventi che sono accettati come argomento dei comandi possono essere:
� un nome di evento simbolico
� un codice evento grezzo (event select + umask) nella forma rNNN, con NNN
il descrittore esadecimale dell'evento
� un evento simbolico del tipo pmu/param1=0x3,param2/ con param1 e
param2 de�niti come formati per la PMU di interesse in /sys/bus/e-
vent_sources/devices/<pmu>/format/*
� un evento simbolico del tipo pmu/con�g=M,con�g1=N,con�g2=K/ con M, N
e K valori numerici, mentre con�g, con�g1 e con�g2 sono de�niti dalle voci
corrispondenti in /sys/bus/event_sources/devices/<pmu>/format/*
Per sfruttare la potenzialità dei performance events e di perf in generale, sono stati
fatti numerosi wrapper attorno a perf. Uno di questi è il già menzionato tool ocperf,
che permette di lanciare perf utilizzando una serie molto più numerosa di eventi
simbolici.
1.3.6 Intel Performance Counter Monitor (PCM)
Intel ha sviluppato un tool chiamato Performance Counter Monitor (PCM) (Fi-
gura 1.21, si veda [8]) che misura molti dei PC presenti sul sistema e mostra il
risultato in metriche innovative. PCM fornisce in tempo reale dati sull'utilizzo dei
core, sul numero di istruzioni ritirate per clock, sulla frequenza del processore e molte
altre statistiche. In particolare si evidenziano le seguenti metriche de�nite da Intel
(si veda [7]):
� INST: numero di istruzioni ritirate da tutti i core
� ACYC: numero di cicli di clock in cui i core erano attivi (nello stato C0)
30
1.4. Software di benchmarking
� TIME(ticks): numero di cicli di clock a frequenza di riferimento (TSC)
� EXEC: istruzioni ritirate sul numero di cicli di clock a frequenza di riferimento
(TSC) ( INSTTIME(ticks)∗#cores)
� IPC: istruzioni ritirate sul numero di cicli di clock in cui il core era attivo
( INSTACYC)
� FREQ: rapporto tra il numero di cicli di clock in cui il core era attivo e il
numero di cicli di clock a frequenza di riferimento (TSC) ( ACYCTIME(ticks)∗#cores)
� AFREQ: rapporto tra il numero di cicli di clock in cui il core era attivo e
il numero di cicli di clock in cui il core era attivo conteggiati a frequenza di
riferimento (TSC) ( ACYCUnhaltedRefCycles)
� PhysIPC: IPC moltiplicato per il numero di thread per core (IPC ∗#threads_per_core)
� PhysIPC%: proporzione del PhysIPC rispetto al massimo valore di IPC (2
per Atom, altrimenti 4). Indica la percentuale di utilizzo dei core nello stato
attivo C0 (PhysIPC : maxIPC = PhysIPC% : 100)
� INSTnom: EXEC moltiplicato per il numero di thread per core (EXEC ∗#threads_per_core)
� INSTnom%: proporzione di INSTnom rispetto al massimo valore di IPC
(2 per Atom, altrimenti 4). Indica la percentuale di utilizzo sull'intervallo
temporale (INSTnom : maxIPC = INSTnom% : 100)
Se il tool viene eseguito indicando un �le di output, in esso PCM stamperà molte
altre metriche per ogni core, come il residency time nei vari processor states, hit e
miss delle cache, ecc...
1.4 Software di benchmarking
Nel campo delle performance dei sistemi informatici è usuale utilizzare degli ap-
positi programmi di benchmarking per testare un sistema e misurarne alcuni indici di
interesse. I software di benchmarking utilizzano dei test standard e ben determinati,
che mettono sotto sforzo certe componenti del sistema (ad esempio il processore, la
scheda video, la memoria, gli apparati di rete). A seconda del proprio campo di
interesse è quindi opportuno conoscere le caratteristiche di uno speci�co benchmark
per poterlo applicare sul sistema in oggetto e ottenere le misurazioni delle compo-
nenti che si vogliono testare. Il punto di forza di un benchmark è la possibilità di
paragonare i risultati che si ottengono da sistemi diversi. In questo modo si possono
31
1.4. Software di benchmarking
mettere a confronto i vari indici di prestazione e capire in cosa di�eriscono i sistemi
testati, quali siano i pregi e i difetti di ciascuno.
Sul mercato vi è una grande quantità di benchmark disponibili che simulano am-
bienti di�erenti e testano svariate componenti. Nel lavoro di tesi sono stati utilizzati
determinati benchmark che permettono di generare un tipo di workload legato alle
risorse computazionali del processore del sistema. Tale workload è servito appunto
come carico elaborativo sul processore, che è stato monitorato per ottenere informa-
zioni sul suo utilizzo e sui performance counters di interesse. Non sono state fatte
considerazioni in merito agli indici di prestazioni ottenuti dai benchmark, non essen-
do attinente con lo scopo della tesi. Si sono presi in considerazione tre benchmark:
RUBBoS, SPECpower_ssj 2008 e CBench.
1.4.1 RUBBoS: Bulletin Board Benchmark
RUBBoS è un benchmark che simula una piattaforma di bulletin board, ovvero un
forum in cui gli utenti scrivono messaggi e interagiscono con la piattaforma. Creato
dal JMOB project (si veda [2]), ha ricevuto aggiornamenti solo �no al 2005. In seguito
sono state fatte delle modi�che da altri sviluppatori per garantire la compatibilità con
le versioni dei software più recenti da cui RUBBoS dipende. La versione utilizzata
in questa tesi (si veda [27]) è scritta in linguaggio Java e PHP. RUBBoS necessita di
un webserver e di un database per essere eseguito, in quanto esso è un vero e proprio
applicativo web. Il benchmark può essere lanciato su una macchina singola oppure
con�gurato in modo da ricevere le richieste da client distribuiti nella rete.
RUBBoS è stato scelto per i nostri scopi in quanto simula un'applicazione web
con cui gli utenti interagiscono. Quindi è assimilabile, anche dal punto di vista
delle tecnologie utilizzate, a molti applicativi che oggi vengono installati su server
aziendali e di cui vengono poi fatti studi di analisi e previsione delle performance. Il
workload di questo benchmark ci ha permesso di stressare il processore imponendo
carichi minori o maggiori a seconda dei test di interesse.
Sono stati però riscontrati molti problemi sia in fase di installazione e con�-
gurazione sia in fase di utilizzo del benchmark. In particolare si è rilevato che il
benchmark, utilizzando la Java Virtual Machine (JVM), avesse certi limiti sul mas-
simo carico che gli si poteva richiedere. Quando veniva richiesto un carico elevato,
il benchmark iniziava ad occupare una quantità di memoria principale via via cre-
scente, che andava a saturare la memoria disponibile sul sistema. Nel momento in
cui partivano le operazioni del garbage collector della JVM, lo scheduler del sistema
operativo assegnava esclusivamente quei processi all'esecuzione, bloccando l'intero
sistema e non permettendo al benchmark di eseguire i suoi test per tutto il periodo
necessario alla pulizia della memoria. Questo problema ha avuto come conseguenza il
fatto che non si potessero raggiungessero livelli di utilizzo tradizionale del processore
32
1.4. Software di benchmarking
oltre l'80% con il carico massimo che si poteva richiedere al benchmark senza che il
sistema si bloccasse.
In generale il benchmarking tramite software J2EE è stato de�nito essere alquanto
impegnativo in quanto vi sono molteplici problemi (tra i quali quelli sopra riscontrati)
che rendono di�cile l'esecuzione del benchmark e l'a�dabilità della misurazione delle
performance di un sistema. Tali problematiche sono state sollevate prendendo in
considerazione RUBiS, un benchmark creato dagli stessi autori di RUBBoS (si veda
[3, 37]).
1.4.2 CBench
CBench è un benchmark sviluppato internamente al Politecnico di Milano (si
veda [32] per una versione precedente del tool). Al suo interno vi è un generatore
di carico che invia delle richieste a un webserver. Per ogni richiesta ricevuta, il
webserver esegue un programma che genera un carico computazionale oneroso sul
processore. Il programma è scritto in linguaggio C ed è completamente CPU bound,
non dipendendo da risorse esterne quali dischi o memoria. Essendo CPU bound,
sappiamo che nel sistema non ci saranno processi in attesa di I/O e quindi tutte
le istruzioni saranno eseguite non appena possibile. Alla �ne della computazione, il
webserver risponde al generatore di carico con i dati che andranno a comporre il �le
di log.
Per riportarci al caso di un applicativo web, abbiamo paragonato una richiesta
al webserver con una richiesta di un utente che interroga un servizio online. Questo
servizio esegue una certa elaborazione e in�ne risponde all'utente. Le distribuzioni di
arrivo e di servizio del benchmark sono completamente con�gurabili. Nel nostro caso
si sono utilizate distribuzioni esponenziali con rate di servizio costante per tutta la
serie di test e rate di arrivo crescente, in modo da incrementare il numero di richieste
al webserver e di conseguenza avere più carico sul sistema.
Il benchmark può anche essere eseguito in una modalità che impone allo scheduler
del sistema operativo di gestire i processi in una coda FIFO. Questa caratteristica è
fondamentale per poter utilizzare i dati di reportistica nello studio di modelli a reti
di code, che utilizzano la politica FIFO per la gestione dei job.
1.4.3 SPECpower_ssj 2008
SPECpower_ssj 2008 è il primo benchmark a de�nire uno standard per la misura-
zione dei consumi energetici legati alle performance di server industriali (si veda [11]).
È stato sviluppato da SPEC, organizzazione no pro�t che de�nisce e produce bench-
mark standard per l'analisi delle performance. SPECpower_ssj 2008 non si limita ad
esercitare del carico computazionale sul processore, ma si occupa di testare anche la
33
1.4. Software di benchmarking
memoria principale, le cache, l'implementazione della JVM e la gestione dei thread
da parte del sistema operativo.
Si è deciso di eseguire dei test con un benchmark prodotto da SPEC in quanto
esso è garanzia di a�dabilità e di aderenza a uno standard condiviso internazional-
mente. Tra i molteplici benchmark prodotti da SPEC è stato scelto SPECpower_ssj
2008 in quanto esegue una suite di test scritti in Java che si comportano come un
applicativo web transazionale. Benchè sia nato per misurare i consumi energetici dei
server, è stato utilizzato come benchmark tradizionale senza e�ettuare misurazioni
di tipo energetico. Non si sono incontrati particolari problemi o di�coltà durante
l'installazione e l'uso del benchmark, che è stato con�gurato molto più velocemente
rispetto agli altri benchmark considerati.
34
Capitolo 2
Motivazioni
2.1 Critica alle metriche tradizionali di utilizzo
In questa sezione si riportano le critiche che sono state recentemente mosse alle
metriche tradizionali di utilizzo di un processore. Si comprenderà il grado di af-
�dabilità dell'uso di tali metriche sui moderni sistemi informatici e si metterà in
evidenza quanto la metrica di utilizzo sia un indice relativo per la valutazione delle
performance.
2.1.1 Utilizzo del processore (CPU time)
All'epoca in cui un processore conteneva solo un core e non vi erano le tecnologie
descritte nella Sezione 1.1, l'utilizzo del processore ottenuto dalla Formula 1.2 era
una metrica accurata che indicava il vero consumo di risorse e la relativa disponi-
bilità rimanente. Per ogni architettura dell'epoca (soprattutto nel caso di utilizzo
di applicativi CPU bound), le performance erano molto più uniformi e predicibili
rispetto ai sistemi odierni. Con l'Utilization Law (Formula 1.8) inoltre era possibile
prevedere in modo accurato l'andamento dell'utilizzo, in quanto aveva una crescita
esattamente lineare con l'aumentare del workload per Service time costanti.
Con l'avvento delle nuove tecnologie si sono iniziati ad avere dei problemi nella
misurazione e nella previsione accurata dell'utilizzo dei processori. Riportiamo le
posizioni di alcune aziende del settore.
2.1.1.1 Intel Corporation
Intel a�erma che con l'introduzione dell'HT la metrica tradizionale di utilizzo
non è più a�dabile in quanto non riporta il vero utilizzo del processore (si veda
[6,8]). Ipotizzando di avere un'architettura con un processore dual core e HT attivo
(speedup ipotetico di 1.25), se due processi sono eseguiti su due core distinti si ha
un utilizzo globale del 50%, con entrambe le operazioni completate nell'unità di
35
2.1. Critica alle metriche tradizionali di utilizzo
tempo. Se invece i due processi sono eseguiti sui due thread di un singolo core,
sfruttando l'HT, allora l'utilizzo sarà sempre calcolato pari al 50%, con la di�erenza
che non vengono completate due operazioni, ma solo 1.25. A conseguenza di ciò,
Intel sottolinea che:
� Bisognerebbe utilizzare uno scheduler che occupa prima i core �sici e poi i
secondi core logici dati dall'HT. Di questo però se ne deve occupare il sistema
operativo.
� L'utilizzo della CPU non è una buona metrica per stimare il carico e�ettivo
sul sistema o l'headroom rimanente.
� Stimare il throughput relativo all'utilizzo di CPU pari al 100%, scalando i dati
raccolti, non è il modo corretto per ottenere il throughput e�ettivo, in quanto
l'utilizzo non è vero indicatore del carico del sistema o della disponibilità residua
di capacità.
Per misurare correttamente le prestazioni dovute a miglioramenti introdotti sulle
architetture, Intel consiglia di utilizzare metriche alternative come la latenza o il
throughput del sistema relativo a un determinato applicativo.
2.1.1.2 Oracle
Il problema dell'a�dabilità della metrica di utilizzo è stato riscontrato anche
sui processori prodotti da Sun, poi acquisita da Oracle (si veda [28, 38, 39]). Viene
infatti sostenuto che programmi di reportistica (come mpstat in Solaris) riportino
solo l'utilizzo relativo allo stato dei thread hardware (ovvero i core logici), il che
non indica quanto il core sia realmente occupato. Oracle concorda sul fatto che
la di�coltà nel calcolare con precisione la metrica di utilizzo derivi dalla crescente
complessità dei sistemi moderni, con l'introduzione di multi core, multi thread e la
condivisione di risorse �siche (cache L3, controller della memoria, ecc...). Oracle si
concentra principalmente sul come considerare gli stati di �idle� e di �stallo� per i
core logici, in particolare mette in evidenza che:
� Se un core logico diventa idle, non vuol dire che l'intero core �sico lo sia, in
quanto potrebbe avere in esecuzione istruzioni per conto dell'altro core logico.
� Solo quando entrambi i core logici diventano idle si può dire che il core �sico
abbia utilizzo pari a zero.
� Il conteggio di CPU time riportato dai tool tradizionali non ri�ette gli e�etti
collaterali della condivisione di risorse tra i core logici e pertanto è impossibile
determinare correttamente quando un core sia idle.
36
2.1. Critica alle metriche tradizionali di utilizzo
� Un thread idle non riduce necessariamente l'utilizzo del core �sico in quanto
l'utilizzo dipende da quanto sia e�ciente il thread ad eseguire le istruzioni.
� Un thread in stallo (per cache miss ad esempio) sui processori SPARC viene
tolto dall'insieme dei thread schedulabili e al suo posto viene fatto eseguire un
thread pronto, il che può avere ripercussioni sia sull'uso delle risorse condivise,
sia sul calcolo dell'utilizzo del core.
Secondo Oracle il sistema operativo dovrebbe avere i dettagli sull'utilizzo delle sin-
gole unità funzionali (ALU, FPU, cache, memoria, ecc...) e dovrebbe conoscere le
caratteristiche del workload per poter riportare all'utente quanto carico sia possibile
inserire ancora nel sistema. Questa analisi, ancora non fattibile dal sistema opera-
tivo, può però essere fatta parzialmente dal capacity planner che abbia una visione
dettagliata del sistema attuale e del tipo di workload che si vuole aggiungere.
Dai test e�ettuati da Oracle risulta che i sistemi moderni presentano delle non
linearità nel rapporto tra utilizzo tradizionale e throughput del sistema: aggiungere
un delta di throughput non si ri�ette in un aumento proporzionale di utilizzo, e
pertanto non si possono e�ettuare previsioni sulle performance utilizzando le leggi
tradizionali. Inoltre viene evidenziato come questa non linearità sia dipendente dal
workload e dall'architettura stessa del sistema.
2.1.1.3 Microsoft Corporation
Anche su sistemi operativi diversi da Linux sono stati evidenziati problemi nel-
l'interpretazione della metrica di utilizzo dei processori. Il tool di monitoraggio più
conosciuto su sistemi operativi Windows di Microsoft è Windows Task Manager. Nel
tool c'è una sezione apposita per tenere monitorate le risorse hardware della mac-
china, che permette di avere una visione d'insieme di tutto il sistema. Microsoft
concorda nel sottolineare come le nuove tecnologie, tra le quali il multithreading, la
variazione di frequenza, le memorie cache condivise, abbiano un impatto sui mecca-
nismi tradizionali di misura dell'utilizzo dei processori (si veda [34]). In particolare
viene posta l'attenzione sui seguenti problemi:
� Condivisione di risorse tra core �sici: gli e�etti dell'uso condiviso di componenti
all'interno del processore, quali le memorie cache, sono dovuti soprattutto al
tipo di workload che viene fatto eseguire sul sistema. Ci sono applicazioni
che possono avere un numero maggiore o minore di accessi alla memoria, che
richiedono più o meno spazio in memoria e che quindi possono so�rire in termini
di prestazioni se le memorie sono condivise con altre applicazioni. Queste
variabilità, correlate tra loro, si ripercuotono sul conteggio dell'utilizzo del
processore.
37
2.1. Critica alle metriche tradizionali di utilizzo
� Condivisione di risorse tra core logici: due thread facenti parte dello stesso
core �sico possono entrare in con�itto per l'utilizzo di certe unità funzionali
che non sono duplicate. Questo comporta che vi siano degli stalli �no a quando
le unità funzionali non sono disponibili all'uso. Infatti non si può paragonare
il lavoro svolto da un core nel caso in cui sia utilizzato al 100% con un solo
processo o nel caso in cui venga utilizzato al 100% ma con i due thread in
funzione parallelamente. Proprio per questo l'SMT non raddoppia il lavoro
che viene svolto, ma ne ottimizza lo svolgimento. Questo scenario rende più
di�cile considerare l'utilizzo di quei core logici che il sistema operativo vede
come se fossero dei core �sici indipendenti.
� Accessi alla memoria alternativi: oggi molti sistemi implementano topologie
NUMA per la memoria principale. Come per la condivisione di risorse tra
core, anche l'accesso alla memoria non uniforme può rendere di�cile capire
quali siano le reali performance di un processore.
� Power managment: con l'implementazione di tecnologie per il risparmio ener-
getico o l'aumento delle prestazioni, la frequenza di un processore può variare
molto repentinamente. Bisogna sottolineare che l'utilizzo viene calcolato senza
tenere conto di queste variazioni di frequenza, e cioè utilizzando la frequenza di
riferimento (TSC). Questo può portare ad avere valori di utilizzo non coerenti
con la reale capacità del processore. Per esempio si possono avere valori di
utilizzo superiori al 100%.
Microsoft quindi consiglia di considerare con cautela la situazione che si sta
analizzando, tenendo a mente alcune indicazioni durante l'analisi del sistema.
2.1.1.4 Adrian Cockroft (Net�ix, eBay, Sun)
Una critica molto forte all'a�dabilità della metrica di utilizzo proviene da Adrian
Cockcroft, ex dipendente di Net�ix, eBay e Sun (si veda [5]). Le tecnologie incri-
minate sono sempre il SMT e il power managment. Vengono però anche citati i
problemi relativi alla metrica di utilizzo negli ambienti virtualizzati, ovvero quando
le risorse �siche dell'hardware vengono assegnate da un hypervisor (il quale incide
sul sistema con il proprio workload) a un sistema operativo ospite.
Viene evidenziato come gli odierni sistemi informatici seguano relazioni di non
linearità dovute soprattutto all'Hyper-Threading, poichè questa tecnologia non sca-
la linearmente come facevano i processori tradizionali. Per questi si sapeva che il
raddoppio del throughput corrispondeva al raddoppio dell'utilizzo del processore se
il sistema non era saturo. Di conseguenza anche il rapporto tra utilizzo e tempo
di risposta cambia. L'HT permette sì di incrementare il throughput, ma rende più
38
2.1. Critica alle metriche tradizionali di utilizzo
di�cile lo studio della capacità del sistema, in quanto il Service time di una CPU
con HT aumenta al crescere del carico sul sistema.
Per quanto riguarda le tecniche di power managment, viene criticato il fatto che
nelle metriche tradizionali raccolte dai tool di capacity planning non si tenga ancora
in considerazione la frequenza di clock media a cui opera il sistema. Specialmente
nel caso in cui la frequenza sia inferiore a quella di lavoro (a causa del power saving)
si ha che il Service time del processore aumenta, dando una visione errata del suo
vero utilizzo. Viene quindi auspicato che in futuro nei sistemi operativi si tenga
in considerazione la velocità istantanea della frequenza di clock durante il calcolo
dell'utilizzo.
2.1.2 Load average
Nella pratica quotidiana si usa considerare il valore del load average soprattutto
per gli intervalli di misurazione di 5 e 15 minuti, in quanto essi danno una visione
a lungo termine di quanto sia carico il sistema. Se il load average ha un valore
minore al numero di core presenti nel sistema, si dice che il sistema sta lavorando in
condizioni di basso carico e non utilizza tutta la sua disponibilità computazionale.
Nel caso sia uguale al numero di core presenti nel sistema, allora si dice che il sistema
sta lavorando a pieno regime ed è in una situazione di carico ottimale in quanto non
diventa mai idle. Quando il valore di load average diventa maggiore del numero di
core, allora si dice che il sistema sta andando verso la saturazione in quanto ha un
carico superiore a quello ottimale. Questo accade perchè il numero di processi in coda
inizia a crescere, mentre i core stanno già lavorando al massimo delle loro capacità.
Si veri�ca quindi un degrado delle prestazioni in termini di throughput e tempi di
risposta. Se il valore di load average dovesse essere maggiore del numero di core in
termini di ordini di grandezza, allora si veri�cheranno sicuramente rallentamenti del
sistema intero, �no eventualmente al suo blocco.
Uno studio di comparazione tra la metrica di utilizzo del processore e il load
average aveva evidenziato come il load average fosse una metrica più precisa in ter-
mini di conoscenza della quantità di carico presente su un processore (si veda [16]).
Nell'ipotesi di un sistema con un carico elevato, tendenzialmente si avrà un utilizzo
pari al 100%, ma questo valore non dice quanti altri job devono ancora essere ese-
guiti, ed è infatti indipendente dalla lunghezza della coda in ingresso al processore.
Il load average invece indica, oltre ai job in esecuzione, quanti job sono in attesa e
pertanto ri�ette in modo più accurato il carico sul sistema (il quale potrebbe avere
un utilizzo del 100% per valori molto di�erenti di load, e quindi dare una percezione
errata dell'e�ettivo carico presente).
Questa metrica, per come è stata de�nita in 1.3.1, risulta essere però molto
application dependent. Ci riportiamo in due casi:
39
2.2. Metriche alternative
1. L'applicazione è CPU bound: il load average tendenzialmente risulterà avere
un valore pari al numero di core sulla macchina. Questo indica che i processori
stanno lavorando al massimo delle loro possibilità.
2. L'applicazione è I/O bound: avendo dei processi che rimangono bloccati in
attesa di risposta dall'I/O, il valore del load average inizierà a crescere oltre al
numero di core. Questo però non rispecchia il fatto che in realtà il processore
sia utilizzato, poichè i processi non consumano risorse computazionali. Il load
average in questo caso sta ad indicare il numero di processi in attesa di poter
essere eseguiti non appena sbloccati, e fornisca un'idea di quanto gli utenti
dovranno attendere per ricevere la loro risposta dal sistema.
Oggigiorno questo ha portato a considerare la metrica di load average come a un
indicatore relativo di quanto il sistema è carico, senza pretendere di essere una me-
trica accurata. Leggendo il valore ci si può subito fare un'idea di quanto lavoro sia
presente sul sistema, in modo da capire grossolanamente come si sta comportando
l'applicativo e quanto richiesta del sistema vi sia da parte dagli utenti. Il load avera-
ge permette di prendere delle decisioni di alto livello, ma non può essere considerato
come una metrica che indica con precisione la capacità del processore.
2.2 Metriche alternative
In questa sezione si riportano alcune metriche alternative a quella tradizionale di
utilizzo, proposte da diverse aziende nell'ambito dei loro sistemi. Esse si basano sia
su concetti teorici applicabili via software, sia su nuove funzionalità delle architetture
implementate in hardware.
2.2.1 Intel Corporation
Nella Sezione 1.3.6 è stato descritto PCM, il nuovo tool di monitoraggio prodotto
da Intel che si basa sull'analisi dei PCs. Con PCM sono state introdotte diverse
metriche alternative all'utilizzo tradizionale, in particolare si ricordano PhysIPC% e
INSTnom%.
PhysIPC% è la percentuale, per core �sico, di quante istruzioni siano state ritirate
per ogni ciclo di clock in cui il core è stato attivo (IPC) rispetto al limite teorico di
istruzioni ritirabili (2 per processori Atom, 4 per le altre famiglie).
INSTnom% è la percentuale, per core �sico, di quante istruzioni siano state ri-
tirate per ogni ciclo di clock a frequenza di riferimento (EXEC) rispetto al limite
teorico di istruzioni ritirabili (2 per processori Atom, 4 per le altre famiglie).
Queste metriche sono molto interessanti, ma hanno il limite di non dare un det-
taglio elevato sul comportamento del singolo core logico, poichè i cicli di clock e
le istruzioni ritirate vengono conteggiate globalmente su tutto il sistema e non per
40
2.2. Metriche alternative
singolo core. Inoltre le percentuali sono calcolate sul limite teorico di istruzioni riti-
rabili, il che verosimilmente non sarà mai raggiunto da alcun processore e quindi la
metrica distorce la percezione della capacità reale del core �sico.
2.2.2 IBM
I processori prodotti da IBM, come quelli della famiglia POWER, hanno im-
plementato via via nuove tecnologie quali l'SMT e la presenza di core e processori
multipli. IBM ha quindi compreso che il metodo tradizionale del calcolo dell'uti-
lizzo sul suo sistema operativo AIX doveva adeguarsi a queste innovazioni in modo
che l'utilizzo del processore fosse correttamente calcolato e interpretato. A partire
dal processore POWER5 è stato introdotto l'SMT in un numero sempre crescente
di hardware thread context (ad esempio il POWER7 gestisce �no a 4 thread hard-
ware), che il sistema operativo AIX considera come core logici. In questo modo
schedulare i thread sui vari core è semplice, ma si ottengono inevitabilmente delle
performance degradate, in quanto due thread sullo stesso core �sico non producono
un throughput di�erente rispetto al caso in cui fossero su due core �sici distinti.
Di conseguenza il metodo tradizionale di calcolo dell'utilizzo produce risultati non
accurati (si veda [15]).
Con il processore POWER5 è stato introdotto per ogni hardware thread context
un nuovo registro chiamato Processor Utilization of Resources Register (PURR). Il
PURR conteggia le unità di tempo in cui un hardware thread ha impegnato delle
risorse �siche del core per svolgere il suo lavoro. Il conteggio viene e�ettuato rela-
tivamente al real time clock (timebase) del processore. Alla �ne di un periodo di
misurazione la somma dei valori dei PURR relativi agli hardware thread in un core
sarà molto vicina alla timebase. Il rapporto tra i PURR e il registro della Timebase
fornisce la frazione di utilizzo del core sull'intervallo di tempo (physc = PURRTimebase).
Questa metrica si rivela essere molto accurata e i tool di reportistica presenti nel
sistema operativo AIX riportano questo valore per ogni core logico. La somma dei
valori di physc di ogni core logico corrisponde all'utilizzo globale delle risorse del
sistema (SysUtil =∑
core physc), dove il valore massimo di SysUtil è pari al numero
di core �sici del sistema.
Sul processore successivo, il POWER6, IBM ha implementato le funzionalità
di dynamic frequency scaling: questo ha portato a un'ulteriore complicazione nel
conteggio dell'utilizzo del processore. IBM ha quindi introdotto un nuovo registro
chiamato Scaled Processor Utilization of Resources Register (SPURR). Il funziona-
mento dello SPURR è simile a quello del PURR, fatta eccezione per il fatto che lo
SPURR viene incrementato in modo proporzionale alla frequenza del core. Quindi
se il core sta lavorando a una frequenza dimezzata rispetto a quella di riferimen-
to, allora lo SPURR viene incrementato la metà delle volte rispetto al PURR. Lo
SPURR sarà incrementato più frequentemente nel caso in cui la frequenza sia au-
41
2.2. Metriche alternative
mentata da tecnologie di turbo. Questa di�erenza si ri�ette sul fatto che il PURR
fornisce la capacità residua basandosi sulla frequenza timebase, mentre lo SPURR
permette di capire la capacità residua e�ettiva tenendo in considerazione la variabi-
lità della frequenza. Su AIX il valore del PURR continua ad essere utilizzato per il
conteggio dell'utilizzo, mentre lo SPURR viene utilizzato soprattutto per il capacity
planning e per contabilizzare quanto un utente abbia sfruttato un core. Il rapporto
tra SPURR e PURR (indicato con %nsp) viene utilizzato per calcolare le variazioni
della frequenza. Tali metriche sono state incluse nei tool di reportistica di AIX.
Il nuovo processore POWER7 ha introdotto la possibilità di utilizzare gli hard-
ware thread in diverse modalità, ovvero in single thread (ST), in SMT2 o in SMT4.
Come riportato in [33] il PURR è stato rivisitato per fornire una precisione ancora
maggiore nel riportare l'utilizzo del processore rispetto ai suoi predecessori. In que-
sto modo si è cercato di ottenere una misura dell'utilizzo del processore che potesse
scalare linearmente rispetto al throughput misurato, come accadeva con i processori
tradizionali. Con questa metrica si raggiunge una relazione quasi lineare per la mag-
gior parte dei workload tipici. Per workload atipici che hanno vantaggi bassi oppure
estremamente elevati dovuti all'SMT4 si possono però ottenere relazioni ancora non
lineari.
2.2.3 Oracle
A partire dal processore UltraSPARC T1 Oracle ha introdotto dei registri speci�-
ci per il monitoraggio delle performance, simili a quelli descritti nella Sezione 1.1.7.1
per le architetture Intel. Si prende come riferimento il processore SPARC T4 (si
veda [29]). Ogni processore virtuale del T4 possiede quattro Performance Control
Registers (PCRs), accessibili in lettura e scrittura solo da utenti privilegiati. Il PCR
viene programmato con il codice di un particolare evento per monitorare ogniqual-
volta accade tale evento sul processore. Ad ogni PCR corrisponde un Performance
Instrumentation Counters (PICs), registro a 32bit che viene incrementato ogniqual-
volta si veri�ca l'evento di interesse indicato nel PCR. Sono disponibili 32 eventi e
relative maschere, che vengono scritti nei campi �sl� e �mask� del PCR.
Questi performance counters sono stati utilizzati da diversi tool su sistema opera-
tivo Solaris, quale ad esempio corestat, che è stato sostituito da pgstat (si veda [30]).
Insieme a pginfo, corestat sfrutta il concetto di Processor Groups (PGs), ovvero un
insieme di CPU che condividono delle componenti hardware rilevanti nella determi-
nazione delle performance (come ad esempio le cache e le pipeline di esecuzione). La
gerarchia di PG che viene a formarsi indica la topologia del processore: alla radice
vi è un PG che contiene tutte le CPU del sistema (che condividono tra loro poco
hardware) e avvicinandosi alle foglie della gerarchia si hanno PG in cui man mano
vi è sempre più hardware condiviso.
42
2.2. Metriche alternative
Per ogni PG, pgstat mostra le statistiche del suo utilizzo hardware basandosi
sui PCR. La percentuale di utilizzo hardware viene calcolata come il rapporto tra
l'utilizzo delle componenti condivise del PG rispetto a un valore stimato del massimo
utilizzo di tali componenti (HW = UTILCAP ).
Allo stesso modo per ogni PG viene riportata la metrica tradizionale di utilizzo dei
thread software, ovvero la percentuale di tempo in cui il thread è stato attivo in modo
utente, sistema o idle in una delle CPU appartenenti al PG (SW = USR+SYSUSR+SYS+IDLE).
In questo modo Oracle dimostra di avere un controllo molto approfondito di
quello che succede nelle varie unità funzionali dei suoi processori e pertanto riesce a
fornire una metrica di utilizzo aderente alla reale attività del processore.
2.2.4 VMware
I problemi relativi alla metrica di utilizzo sono evidenti anche in ambito virtualiz-
zato. Il layer di virtualizzazione può allocare dinamicamente le risorse disponibili, a
seconda del loro stato o del loro utilizzo, alle macchine virtuali. Questo rende ancora
più di�cile ottenere informazioni corrette sull'utilizzo del processore da parte delle
singole macchine virtuali o degli applicativi al loro interno.
Sul sistema operativo vSphere VMware mette a disposizione dei performance
counter relativi alle macchine virtuali in esecuzione (si veda [40]). Tali performance
counter possono essere usati dall'utility Perfmon all'interno dei sistemi virtualizzati
Windows. Con Perfmon quindi gli amministratori possono accedere a statistiche
accurate sull'utilizzo della macchina virtuale.
Dal lato dell'amministrazione di vSphere invece il tool più utilizzato è esxtop, un
tool simile a top per sistemi VMware. Le metriche che vengono presentate da esxtop
sono diverse rispetto a quelle di top, in quanto deve tenere rappresentare un sistema
che è condiviso tra macchine virtuali (si veda [43]).
Si de�nisce PCPU un contesto di esecuzione hardware �sico: una PCPU cor-
risponde a un core �sico se l'HT è disattivo, mentre se l'HT è attivo una PCPU
corrisponde a un core logico. Quindi VMware con il termine core intende un core
�sico, il quale può avere una o due PCPU a seconda che l'HT sia spento o acceso.
Tra le metriche presenti in esxtop si evidenziano le seguenti:
� PCPU UTIL(%): percentuale di cicli di clock in cui la PCPU è rimasta in
stato attivo C0 (unhalted) a frequenza di riferimento (TSC) e la sua media su
tutte le PCPU. Indica quindi quanto tempo la PCPU ha svolto lavoro utile
nell'intervallo considerato.
� CORE UTIL(%): percentuale di cicli di clock trascorsi per core quando
almeno una delle PCPU nel core è unhalted, oltre alla media sui core. È visibile
solo se l'HT è attivo. La percentuale di utilizzo di un core non corrisponde alla
43
2.2. Metriche alternative
somma delle PCPU UTIL(%). In generale si ha:
max(PCPU0_UTIL%,PCPU1_UTIL%) 6 CORE0_UTIL% ≤min(PCPU0_UTIL%+ PCPU1_UTIL%, 100%)
� CORE IDLE(%): inverso di CORE UTIL(%), indica la percentuale di cicli
di clock trascorsi per core quando entrambe le PCPU nel core sono in stato di
idle, ovvero halted.
� PCPU USED(%): percentuale di utilizzo della CPU per ogni PCPU (numero
di cicli unhalted rispetto all'intervallo di misurazione), oltre alla sua media tra
tutte le PCPU. Questa metrica indica il lavoro e�ettivo svolto dalla PCPU.
Di�erisce dalla metrica PCPU UTIL(%) a causa di tecnologie quali:
1. Hyper-Threading: le PCPU condividono risorse hardware nel core, quindi
questa metrica varia a seconda che una o entrambe le PCPU siano usate.
Ad esempio quando una sola PCPU lavora mentre l'altra è idle si ha un
maggiore lavoro e�ettivo da parte di quella PCPU rispetto a quando en-
trambe le PCPU lavorano contemporaneamente. Lo scheduler di VMware
per far fronte a ciò mette in conto a ogni PCPUmetà del tempo trascorso
quando entrambe sono in esecuzione. Se solo una è in esecuzione, allora
le sarà addebitato l'intero periodo temporale. Questo permette di consi-
derare i casi in cui entrambi i thread dell'HT sono utilizzati. In generale
per ogni PCPU si ha:
PCPU0_UTIL% ≥ PCPU0_USED% ≥
PCPU0_UTIL%2 se PCPU0_UTIL% <
PCPU1_UTIL%
(PCPU0_UTIL%− PCPU1_UTIL%) altrimenti
+PCPU1_UTIL%
2
Questa disequazione può non essere veri�cata se vi sono variazioni di
frequenza.
2. Power Managment: a causa della variazione di frequenza di una PCPU,
lo scheduler ricalcola la PCPU_USED(%) basandosi sulla frequenza della
PCPU. Quindi si ha che:
PCPU_USED% = PCPU_UTIL% ∗ Frequenza e�ettivaFrequenza nominale
44
2.3. Limiti della metrica di utilizzo
Questa relazione può essere utilizzata all'interno di quella precedente per
tenere in considerazione entrambi i fattori. Nel caso in cui la frequenza
e�ettiva vada oltre a quella nominale (turbo mode), allora PCPU USED
(%) può risultare essere maggiore di PCPU UTIL(%) ed andare oltre al
100%.
2.2.5 Adrian Cockroft
In [5] Cockroft propone una metrica chiamata �headroom�, de�nita come la parte
ancora inutilizzata del throughput massimo possibile. Questa metrica vuole indicare
quanto spazio libero sia ancora disponibile sul sistema in modo da occuparlo con
workload addizionale. In particolare vengono distinti due casi, che di�erenziano per
l'ambito di applicazione:
1. Nel caso di sistemi semplici non industriali, si lega il concetto di headroom a
quello di utilizzo tradizionale. L'headroom viene de�nito come �uno meno il
margine meno l'utilizzo�. Supponendo di avere un sistema realmente utilizzato
per il 65% e si è deciso che il massimo utilizzo accettabile sia l'80%, quindi un
margine del 20% dal massimo utilizzo. Allora si ha che headroom = 100−20−65 = 15. Se la frequenza di funzionamento è variabile, allora si può usare la
frequenza di clock media per stimare la capacità attuale e calcolare l'headroom
basandosi sulla capacità ottenuta a frequenza di clock massima.
2. Nel caso di sistemi complessi, come server industriali, l'headroom dovrebbe
legarsi con i concetti di throughput e response time. In questo caso l'headroom
viene calcolato come percentuale del throughput attuale rispetto al throughput
massimo che il sistema può sostenere.
Questa metrica è stata valutata durante il lavoro di tesi, ma non è sembrata ottimale
in quanto nel primo caso si lega ancora all'utilizzo tradizionale (e quindi ai limiti del
suo calcolo). Nel secondo caso invece non è sempre possibile considerare il throughput
massimo durante l'analisi di un sistema. Questo perchè non vi è l'intenzione di
eseguire un test di carico su un sistema di produzione, ma si e�ettua il capacity
planning solo sui dati ottenuti dal rilevamento attuale delle prestazioni.
2.3 Limiti della metrica di utilizzo
Si prendono ora in considerazione i problemi principali che incidono sull'a�dabi-
lità della metrica di utilizzo tradizionale. Tali problemi verranno descritti utilizzando
le tecnologie implementate da Intel sulle sue architetture. Questa scelta è stata det-
tata dalla necessità di avere una metrica alternativa per i sistemi Intel, benchè il
modello proposto verrà de�nito in modo tale da poter essere implementato su altre
45
2.3. Limiti della metrica di utilizzo
architetture che espongono tecnologie funzionalmente equivalenti. I problemi de-
scritti rappresentano le cause principali al comportamento non lineare della metrica
di utilizzo tradizionale, che non riesce più nè ad analizzare lo stato di un sistema con
precisione, nè ad e�ettuare previsioni accurate.
2.3.1 Problema 1: Hyper-Threading
Si è già discusso di quanto la metrica di utilizzo tradizionale non rispecchi fedel-
mente ciò che accade all'interno del processore durante l'attività contemporanea dei
core logici. Questo succede a causa di molteplici fattori, come ad esempio la com-
petizione per le risorse condivise. Possono esserci casi in cui l'utilizzo ha un valore
elevato benchè a tutti gli e�etti il core �sico non venga utilizzato al pieno delle sue
capacità. D'altra parte si è anche evidenziato un comportamento non lineare tra
l'utilizzo tradizionale del core e il throughput associato, fatto che non permette di
avere una chiara idea di quanta capacità residua sia presente nel sistema. Far ese-
guire due thread hardware sullo stesso core �sico ha quindi introdotto una notevole
di�coltà nel capire lo stato di un sistema mediante l'utilizzo tradizionale e pertanto
è fondamentale trovare un modello che riesca a tenere in considerazione l'HT.
2.3.2 Problema 2: Dynamic frequency scaling
Le tecnologie di power managment, come il power saving e il Turbo Boost, per-
mettono di variare la frequenza del processore nel caso in cui esso abbia più o meno
carico da elaborare. Esse sono legate strettamente al governor che viene imposta-
to sul sistema. Questi aspetti di variazione di frequenza non vengono mai tenuti
in considerazione nel calcolo dell'utilizzo tradizionale. Esso viene infatti calcolato
considerando i cicli in cui il processore è rimasto attivo nell'intervallo di misurazio-
ne rispetto alla frequenza di riferimento (TSC), che quindi è invariante rispetto ai
cambi di frequenza. Perciò succede che con l'aumentare delle frequenze di lavoro si
ottenga lo stesso valore di throughput in corrispondenza di un utilizzo inferiore del
processore.
Tenere in considerazione la possibilità che il processore possa avere delle variazioni
di frequenza è importante per calcolare un valore di utilizzo non dipendente dalla
frequenza di riferimento (TSC), valore che è molto fuorviante rispetto allo stato
reale di utilizzo del processore. Inoltre considerare la variabilità della frequenza è
fondamentale per capire quante istruzioni in più il processore possa elaborare se viene
fatto lavorare alla sua frequenza massima.
46
2.4. Capacity planning
0 200 400 600 800 1000 1200 1400 1600 1800 20000
10
20
30
40
50
60
70
80
90
100
Utilization Law applicata a un sistema conHT e Dynamic frequency scaling
Misurato
Previsione
Effettivo
Throughput (req/s)
Utiliz
zo
Figura 2.1: Previsione dell'utilizzo di un sistema con HT e Dynamic frequency sca-ling. La previsione non viene confermata dai dati e�ettivi ad alto carico in quantohanno un comportamento non lineare.
2.4 Capacity planning
Come già evidenziato nella Sezione 1.2.2, la metrica di utilizzo viene utilizzata
in modo preponderante nella pratica industriale di dimensionamento e stima delle
capacità di un sistema. I problemi relativi a tale metrica che sono stati sollevati nel
corso di questo capitolo convergono tutti nella questione di poter e�ettuare non solo
un'analisi in tempo reale dei sistemi corretta, ma anche nel fatto di poter eseguire
un'analisi di previsione dell'utilizzo del sistema esente dagli errori insiti nel valore
dell'utilizzo tradizionale.
Abbiamo riportato come sia stato sollevato da diversi soggetti il problema del-
la non linearità del rapporto tra utilizzo e throughput. Eseguendo una regressione
lineare utilizzando l'Utilization Law (Formula 1.8) si ottiene che i valori stimati di-
vergono in modo più o meno accentuato da quanto viene invece misurato sul sistema.
Questo andamento non lineare dipende sia da come è calcolato l'utilizzo del siste-
ma (e quindi da quale architettura e quali tecnologie siano presenti sul sistema) ma
anche dalle caratteristiche del workload che viene eseguito (come applicativi CPU
intensive oppure I/O intensive). Il comportamento è visibile in Figura 2.1, in cui
si evidenzia come la previsione che viene fatta utilizzando i dati misurati a basso
carico (i dati in blu) non venga poi confermata dai dati e�ettivi che sono stati misu-
rati successivamente aumentando il carico sul sistema (i dati in arancione). Si può
quindi supporre che l'andamento non lineare sia dovuto al fatto che il sistema sfrutti
47
2.4. Capacity planning
sempre più il secondo thread hardware del processore e ne aumenti la frequenza di
lavoro in modo da soddisfare il workload via via crescente. Lo stesso comportamento
viene mostrato in [39], dove però non viene proposta nessuna metrica alternativa per
stimare precisamente l'utilizzo del sistema.
Una previsione e�ettuata con questa metodologia su un sistema che si comporta
come quello in Figura 2.1 può portare a dei risultati strategici inesatti e quindi a
grandi problemi di performance e di qualità del servizio per gli utenti �nali. Questo
si ripercuote in un danno economico e di immagine per l'azienda a cui è stata stimata
erroneamente la capacità dei server con cui o�re i suoi servizi. Dire che il throughput
del sistema può essere raddoppiato senza che questo vada in saturazione può rivelarsi
incorretto e far saltare il sistema ben prima del raddoppio del throughput, poichè
l'utilizzo cresce �più velocemente� di quanto non cresca il throughput.
Questa tesi si propone quindi di ideare una metrica alternativa all'utilizzo tradi-
zionale per poter eseguire un'analisi realistica che tenga in considerazione le caratte-
ristiche tecnologiche del sistema. Inoltre tale metrica deve poter essere utilizzata per
stimare la capacità e�ettiva futura del sistema tramite la misura delle sue prestazioni
a basso carico, come fatto usualmente nella pratica industriale. Nella Sezione 2.2 si
sono mostrate alcune metriche proprietarie che sono state implementate per risolvere
il problema che è stato appena posto, ma nessuna è stata ancora proposta da Intel
per le sue architetture. Poichè Intel ha un grande market share nella vendita di
processori per server è comune avere a che fare con tali processori nell'eseguire uno
studio di capacity planning e pertanto è importante trovare una metrica che colmi
questa mancanza.
48
Capitolo 3
Modello proposto
3.1 La produttività del processore
Le a�ermazioni delle aziende del settore, riportate nella Sezione 2.1, ci spingono
quindi a sviluppare un modello che fornisca una metrica alternativa di utilizzo. Tale
modello deve essere il più indipendente possibile dall'architettura su cui si basa,
in modo che possa essere applicato ai sistemi prodotti da qualsiasi azienda. In
particolare, vista la necessità di avere una metrica per le architetture basate su
processori Intel, il modello sarà implementato con le tecnologie o�erte da questa
azienda. Ciò non preclude una sua successiva implementazione su altre architetture,
in quanto i fondamenti concettuali su cui si basa il modello sono de�niti in modo
indipendente. Se una architettura espone quindi le tecnologie che forniscono i dati
necessari al modello, sarà possibile allora implementarlo su tale architettura.
Il modello che è stato ideato presenta molte di�erenze rispetto a come era stata
de�nita la metrica tradizionale di utilizzo (si veda Formula 1.2). Con la nuova metrica
si vuole spostare l'attenzione dal considerare quanto venga usato un processore in
termini di tempo speso nello stato unhalted alla concezione di utilizzo relativo alla
quantità di lavoro utile svolto dal processore. Non ci si vuole più riferire quindi al
tempo trascorso nello stato attivo C0, bensì al numero di istruzioni che il processore
ha ritirato. Il fatto di considerare quando un'istruzione viene ritirata tiene conto
di tutte quelle problematiche relative ai tempi di attesa dell'I/O, dei problemi di
condivisione delle risorse e dei cambiamenti nella frequenza. Un'istruzione viene
ritirata infatti quando è terminata la sua esecuzione e il risultato può essere applicato
allo stato architetturale della macchina.
La metrica proposta dovrà avere una crescita lineare con l'aumentare del throu-
ghput del sistema. Inoltre dovrà tenere in considerazione le principali tecnologie dei
moderni processori che oggi non permettono un comportamento prevedibile e a�da-
bile dell'utilizzo tradizionale. Solo in questo modo si potranno ottenere delle analisi
e delle stime corrette sulla reale capacità del sistema.
49
3.1. La produttività del processore
Thread 1 Thread 2
t
TD1
Core
Figura 3.1: Cicli di clock trascorsi dal primo thread nello stato attivo. Il core �sicolavora a TD1 per l'intero periodo.
3.1.1 Densità dei thread
Nei processori Intel è stato introdotto l'Hyper-Threading come implementazione
dell'SMT2. Grazie all'HT il sistema operativo ha a disposizione due thread hardware
per ogni core �sico. Tali thread, chiamati anche core logici, vengono visti dal sistema
operativo come core �sici veri e propri. Il sistema operativo può quindi decidere, a
seconda della situazione, se sfruttare contemporaneamente entrambi i core logici
oppure utilizzare solamente uno di essi.
De�niamo Thread Density (TD) il numero di thread hardware attualmente in
uso sul core �sico. Si presentano quindi tre scenari:
� Nessun thread viene utilizzato: non si hanno thread attivi e pertanto si ha una
TD pari a zero. Questo caso non è di nostro interesse in quanto il sistema è
idle e non sta svolgendo lavoro.
� Un solo thread è utilizzato: si ha allora TD pari a uno, indicata con la sigla
TD1 (Figura 3.1).
� Entrambi i thread sono utilizzati: si ha allora TD pari a due, indicata con la
sigla TD2 (Figura 3.2).
Il processore non funziona mai esclusivamente a TD1 o a TD2, infatti capita spesso
che un solo thread sia attivo e in un secondo momento venga attivato anche il secondo
thread, in un'alternanza che dipende da come lo scheduler decide di assegnare i
processi ai core logici (Figura 3.3). Nelle �gure sopra citate si evidenzia come le
barre azzurre e la barra grigia indichino rispettivamente il periodo di tempo in cui
il thread o il core �sico (al quale appartengono i due thread) è rimasto nello stato
C0. Tale intervallo temporale corrisponde al numero di cicli di clock in cui il thread
è rimasto unhalted, mentre per il core �sico indica il numero di cicli di clock in cui
almeno uno dei due thread era attivo.
50
3.1. La produttività del processore
Thread 1 Thread 2
t
TD2
Core
Figura 3.2: Cicli di clock trascorsi da entrambi i thread nello stato attivo. Il core�sico lavora a TD2 per l'intero periodo.
Thread 1 Thread 2
t
TD1
TD2
TD1
Core
Figura 3.3: Cicli di clock trascorsi da entrambi i thread nello stato attivo. Il core�sico lavora a TD variabile durante il periodo.
51
3.1. La produttività del processore
Si de�nisce Average Thread Density (ATD) il numero medio di thread attivi che
sono utilizzati dal core �sico durante il periodo di misurazione. L'ATD ha quindi un
valore compreso tra uno e due per i processori con SMT2.
3.1.2 Instructions per Cycle (IPC)
Vi sono due casistiche che si è deciso di a�rontare mediante l'introduzione nel
modello della metrica di Instructions per Cycle (IPC) e del suo inverso Cycles per
Instruction (CPI).
L'IPC viene de�nito come metrica sul singolo core logico ed è il rapporto tra il
numero di istruzioni ritirate dal core e il numero di cicli di clock trascorsi dal core
nello stato attivo C0. La CPI viene de�nita come inverso dell'IPC.
Il primo caso riguarda il fatto che per ritirare un'istruzione il processore abbia
avuto degli stalli o abbia dovuto dare precedenza ad altre istruzioni: il numero di
cicli di clock totali che sono intercorsi dall'issue dell'istruzione al suo retire vengono
inglobati nell'IPC (o CPI).
Lo stesso capita per il secondo caso, ovvero quando vi sono istruzioni che vengono
eseguite dal processore ma che non vengono ritirate (ad esempio per branch mispre-
cition). Il processore ha comunque tenuto impegnate delle risorse computazionali
senza ottenere un lavoro concreto come risultato.
Quello che ci interessa in questo caso è una metrica che riporti una media globale
di quante istruzioni il processore riesca a ritirare in un ciclo di clock per il dato
workload dell'applicativo, e viceversa quanti cicli servano mediamente per ritirare
un'istruzione. Nel CPI quindi riusciamo a inglobare anche quei cicli delle due situa-
zioni descritte sopra, che non portano un lavoro utile ma per le quali il processore è
rimasto comunque attivo. Queste metriche duali forniscono una visione d'insieme di
quanto lavoro utile (quindi che ha e�etti sullo stato architetturale della macchina)
riesca mediamente a svolgere il processore.
3.1.3 Ricavare la metrica
Si prenda come riferimento la Figura 3.3, che rappresenta il caso più generico di
parallelismo tra thread hardware. Possiamo ottenere il numero di cicli di clock totali
eseguiti quando nel core sono attivi entrambi i thread (quindi a TD2) e lo indichiamo
con Cycles_td2. Cycles_td2 sarà uguale alla somma dei cicli dei due thread meno
i cicli dell'intero core quando almeno uno dei due thread è attivo (indicato con
Cycles_core). Possiamo ora calcolare il numero di cicli di clock totali eseguiti quando
nel core è attivo un solo thread (quindi a TD1) e lo indichiamo con Cycles_td1.
Cycles_td1 sarà uguale al numero di cicli dell'intero core meno il numero di cicli a
52
3.1. La produttività del processore
TD2 appena calcolato. In formula:
Cycles_td2 = (Cycles_thread1+ Cycles_thread2)− Cycles_core (3.1)
Cycles_td1 = Cycles_core− Cycles_td2 (3.2)
I cicli a TD1 e a TD2 indicano quindi per quanto tempo il core ha lavorato esclusiva-
mente con uno o con due thread. Si noti bene che i cicli unhalted misurati non sono
riportati alla frequenza di riferimento (TSC) e pertanto sono sensibili alla variazione
di frequenza dovuta al dynamic frequency scaling.
Durante l'intervallo in cui vengono conteggiati i cicli, si conteggiano anche le
istruzioni che vengono ritirate dai due thread. Tali istruzioni vengono sommate per
ottenere il totale delle istruzioni ritirate dal core. In formula:
Instr_tot = Instr_thread1+ Instr_thread2 (3.3)
Il totale delle istruzioni ritirate deriva dall'apporto dei singoli thread e quindi è dipen-
dente dal fatto che un solo thread oppure entrambi fossero in esecuzione. Possiamo
quindi considerare il totale delle istruzioni come somma delle istruzioni ritirate a
TD1 e delle istruzioni ritirate a TD2 (Instr_td1 e Instr_td2). Tali valori a loro
volta possono essere visti come il prodotto del numero di cicli a TD1 o a TD2 con
il numero medio di istruzioni ritirate per ciclo, ovvero gli IPC a TD1 e a TD2. In
formula:
Instr_tot = Instr_td1+ Instr_td2 = (3.4)
Cycles_td1 ∗ IPC_td1+ Cycles_td2 ∗ IPC_td2
In questa equazione gli unici valori ignoti sono IPC_td1 e IPC_td2 ed è quindi
possibile utilizzare una regressione lineare multivariata per stimarne i valori. Tale
regressione verrà e�ettuata utilizzando i dati raccolti dal sistema che si sta analiz-
zando, nello speci�co si tratta di acquisire le istruzioni ritirate dal core �sico e i cicli
di clock trascorsi sia per i core logici sia per il core �sico.
A questo punto siamo interessati a sapere cosa succede nel caso peggiore di fun-
zionamento, ovvero quando sul sistema viene applicato un workload molto pesante.
Sappiamo che lo scheduler del sistema operativo, consultando il governor impostato,
farà lavorare il sistema al massimo delle sue possibilità. Pertanto dobbiamo consi-
derare che la frequenza del processore verrà aumentata �no al suo limite massimo e
che lo scheduler faccia lavorare i processi su entrambi i thread, arrivando a raggiun-
gere teoricamente la condizione di TD2. In questa condizione il numero massimo
di istruzioni che il processore può ritirare, indicato con Instr_max_td2, è pari al
prodotto tra la frequenza massima di funzionamento e il valore stimato di IPC_td2.
Si suppone infatti che potendo raggiungere la condizione di TD2 a causa dell'alto
53
3.1. La produttività del processore
carico, il processore potrà allora ritirare un numero di istruzioni per clock pari al
valore stimato IPC_td2. In formula:
Instr_max_td2 = Core_max_frequency ∗ IPC_td2 (3.5)
Si evidenzia come questo ragionamento possa essere applicato anche nel caso in cui
l'Hyper-Threading sia disattivato sul sistema. Nel caso di alto carico si avrà una
situazione in cui il numero massimo di thread nel core �sico è solo uno e quindi
si ha TD1. Per ottenere le istruzioni massime si moltiplicherà sempre la frequenza
massima per il valore stimato di IPC_td1. In formula:
Instr_max_td1 = Core_max_frequency ∗ IPC_td1 (3.6)
Finalmente possiamo de�nire la nuova metrica di produttività del processore, che
viene chiamata productivity. Essa è calcolata nella condizione di più alto carico del
sistema, ovvero a TD2 (simmetricamente si ottiene per il caso a TD1). La produc-
tivity viene calcolata come rapporto tra le istruzioni attualmente ritirate (Formula
3.3) e la stima delle istruzioni massime ritirabili a TD2 (Formula 3.5). In formula:
Productivity =Instr_tot
Instr_max_td2(3.7)
La productivity rappresenta quindi la metrica che indica la capacità e�ettiva del pro-
cessore di ritirare istruzioni completate, cambiando la concezione di utilizzo basato
sul tempo trascorso dal processore nello stato busy. Per calcolare la productivity
media dell'intero sistema è su�ciente fare la media tra le productivity di tutti i
processori, o core �sici, presenti nel sistema.
3.1.4 Problema 1: Hyper-Threading
Poichè nel calcolo della productivity viene considerato il numero di istruzioni
ritirate, il problema relativo alle dinamiche complesse dovute all'HT viene risolto. Si
riesce infatti a capire sia quanto un thread hardware venga utilizzato sia quanto esso
entri in con�itto con il secondo thread: in questi casi si avranno delle ripercussioni
sul numero di istruzioni che ciascuno di essi ritira. Il contributo di ogni thread in
termini di istruzioni ritirate sarà quindi rappresentativo delle loro interdipendenze
e verrà utilizzanto correttamente nella media che viene calcolata sull'intero sistema.
Quindi se un core logico dovesse lavorare meno a causa di un contenzioso di risorse
con l'altro core logico, esso dovrà ritirare un numero di istruzioni inferiore. Questo
permette di risolvere il problema relativo al considerare, nella metrica tradizionale di
utilizzo, quanto tempo un core logico sia in stallo a causa di dipendenze con l'altro
core logico, valore che viene solitamente incluso nella metrica di utilizzo.
54
3.1. La produttività del processore
3.1.5 Problema 2: Dynamic frequency scaling
Il problema del dynamic frequency scaling viene risolto agendo su due fronti: il
conteggio del numero di istruzioni e dei cicli di clock.
Il numero di istruzioni ritirate è anche funzione della frequenza di lavoro del pro-
cessore. L'utilizzo tradizionale, che si basava sul tempo trascorso calcolato a frequen-
za di riferimento, era assolutamente ignaro dei cambi di frequenza che avvenivano
nel processore. Mettendo da parte il concetto di tempo trascorso e concentrandosi
sul numero di istruzioni ritirate è immediato comprendere che le tecniche di dynamic
frequency scaling permettono di accelerare o decelerare la velocità con cui le istruzio-
ni vengono ritirate, in quanto il processore lavora più o meno velocemente. Questo si
rispecchia nella productivity con una rapidità più o meno accentuata nell'incremen-
to del numero di istruzioni, indice del fatto che sul sistema sono intervenute delle
variazioni di frequenza. Ad esempio quando il sistema lavora alla frequenza mas-
sima permessa dal Turbo Boost, esso riuscirà a velocizzare le operazioni di calcolo
necessarie alle istruzioni CPU bounded e pertanto potrà mediamente ritirarle più
velocemente. Al contrario accade nel caso del power managment, in cui la frequenza
di lavoro diminuisce e pertanto le istruzioni vengono ritirate meno di frequente in
quanto ci mettono più tempo per essere completate.
Alla base della productivity vi è il conteggio dei cicli di clock in cui il processore
è stato attivo. Tali cicli di clock vengono conteggiati tenendo in considerazione le
variazioni della frequenza, in quanto non si utilizza la frequenza di riferimento (TSC).
Questo permette di sapere quanti cicli di clock e�ettivamente il thread ha lavorato,
ottenendo di conseguenza il numero medio di istruzioni per ciclo di clock.
3.1.6 Applicabilità della metrica
Una nota d'obbligo da fare è relativa all'applicabilità della metrica appena de�-
nita. La productivity è fortemente legata sia alle speci�che caratteristiche hardware
dell'architettura sia alla speci�ca con�gurazione software presente sulla macchina,
quale il sistema operativo, tutto il software installato e soprattutto l'applicativo che
viene eseguito. La productivity infatti viene calcolata eseguendo una stima che si
basa su dati raccolti dalla macchina durante l'esecuzione dell'applicativo di interesse.
In questo modo si ottiene un modello che descrive come si comporta quell'applicazio-
ne su quella speci�ca macchina e permette di fare una stima della sua productivity
all'aumentare del throughput richiesto.
I valori ottenuti dall'esecuzione dell'applicativo su macchine diverse o dall'ese-
cuzione di un diverso applicativo sulla medesima macchina non sono considerati
paragonabili in quanto l'analisi si basa su dati che sono intrinsecamente correlati alla
speci�ca con�gurazione hardware e software.
55
3.2. Raccolta dei dati
3.2 Raccolta dei dati
3.2.1 Monitoring dell'applicazione
Grazie alla disponibilità dei nuovi Hardware performance counters presenti sulle
architetture Intel, è molto agevole la raccolta dei dati che servono nel calcolo della
productivity. Per il monitoraggio dei PC del sistema si è adottato il tool ocperf,
wrapper del noto tool perf. Ocperf mette a disposizione una lista con molti eventi
simbolici che è possibile monitorare, nel nostro caso siamo interessati ai seguenti
eventi:
� instructions: misura il numero di istruzioni ritirate dal thread hardware. Nel
modello questi valori sono stati chiamati Instr_thread1 e Instr_thread2.
� cpu_clk_unhalted.thread: misura il numero di cicli di clock per cui il
thread hardware è unhalted, ovvero è attivo nello stato C0. Nel modello questi
valori sono stati chiamati Cycles_thread1 e Cycles_thread2.
� cpu_clk_unhalted.thread_any: misura il numero di cicli di clock per cui
almeno uno dei due thread hardware presenti sullo stesso core �sico è unhalted,
ovvero è attivo nello stato C0. Nel modello questo valore è stato chiamato
Cycles_core.
� cpu_clk_unhalted.ref_tsc: misura il numero di cicli di clock a frequenza di
riferimento (TSC) per cui il thread hardware è unhalted, ovvero è attivo nello
stato C0. Chiamiamo questi valori Cycles_ref_thread1 e Cycles_ref_thread2.
Questi valori saranno utilizzati per calcolare altre metriche descritte nella
Sezione 3.3.
Questi eventi vengono monitorati contemporaneamente per tutti i core logici visibili
dal sistema operativo. Bisogna evidenziare che questi dati dovranno essere divisi
per la lunghezza dell'intervallo di misurazione, in modo da riportare le quantità a
una media su un secondo. Un intevallo di misurazione pari a un secondo è quindi
consigliabile ma non obbligatorio.
La raccolta dei PC non introduce alcun overhead in termini di utilizzo del proces-
sore durante l'esecuzione del workload. Si è visto che monitorare o non monitorare
i PC durante nell'esecuzione dei benchmark che sono stati scelti in questa tesi (si
veda 1.4) non ha portato di�erenze sensibili nell'utilizzo tradizionale del processore.
3.2.2 Informazioni sul sistema
Nel calcolo della productivity dell'intero sistema entrano in gioco anche le carat-
teristiche del processore e del sistema operativo. In particolare dobbiamo ricavare:
la frequenza massima di lavoro del processore, che è dipendente dal turbo boost e dal
56
3.3. Calcolare altre metriche con i PC
numero di core logici attivi; la frequenza nominale che viene pubblicizzata nel nome
del processore; il numero di modello del processore, che indica il tipo di processore
all'interno della sua famiglia; la topologia del processore in termini di numero di
socket, di core �sici e di core logici, oltre a come sono associati i core logici fratelli;
il governor attualmente impostato sul sistema operativo.
Tutti questi dati vengono raccolti tramite alcuni tool o sono letti direttamente
da �le del sistema operativo:
� lscpu: tool che mostra varie informazioni riguardo l'architettura della CPU.
Quelle di nostro interesse sono il Model name, il Model, le Socket(s), i Core(s)
per socket, i Thread(s) per core, le CPU(s) online e CPU max MHz che è la
frequenza massima pubblicizzata raggiungibile con il turbo boost.
� rdmsr: tool che permette di leggere gli MSRs. In base alla famiglia del proces-
sore bisogna consultare gli Intel Software Developer's Manuals (si veda [9]) per
sapere l'indirizzo dei registri che sono denominati MSR_PLATFORM_INFO
e MSR_TURBO_RATIO_LIMIT. Questi registri contengono il Base Opera-
ting Ratio e il Maximum Ratio Limit, che sono i moltiplicatori per ottenere
la Base Operating Frequency e la Core Max Frequency mediante la frequenza
di clock del bus de�nita per il Model del processore (Bus Clock Frequency,
BCLK).
� /sys/devices/system/cpu/cpu*/topology/thread_siblings_list: for-
nisce la lista di come sono accoppiati i core logici, ovvero gli hardware thread
che sono fratelli sullo stesso core �sico.
� /sys/devices/system/cpu/intel_pstate/no_turbo: indica se il turbo
boost è attivo (valore 0) o disattivo (valore 1)
� /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor: riporta il
governor attualmente impostato sulla CPU numero zero, che è quella di
riferimento del sistema operativo.
3.3 Calcolare altre metriche con i PC
I dati raccolti nella Sezione 3.2 permettono di calcolare anche altre metriche, tra
cui alcune di uso tradizionale. I valori ottenuti dal calcolo di queste metriche con i
PC sono stati confrontati con quelli monitorati direttamente dal sistema operativo
tramite tool tradizionali quali top, sar e turbostat. Il confronto ha evidenziato una
esatta uguaglianza, evidenziando come tali metriche siano quindi ottenibili anche
tramite i PC. Si spiega quindi come ottenere tali metriche.
57
3.3. Calcolare altre metriche con i PC
3.3.1 Average Thread Density (ATD)
L'ATD di un core �sico è stato de�nito nella Sezione 3.1.1. Se viene fatta la
media degli ATD di tutti i core �sici del sistema, si ottiene l'ATD medio del sistema.
Questo indice è utile per capire quanti thread hardware mediamente vengono utiliz-
zati durante l'esecuzione del workload. Si potrà notare come, in un caso generale,
tale valore tenda ad aumentare con l'incrementare del carico posto sul sistema.
L'ATD di un core �sico viene calcolato come segue. Si de�nisce percentuale
di cicli di clock a TD1 il rapporto tra Cycles_td1 con Cycles_core: tale rapporto
indica la percentuale del tempo in cui un solo thread hardware era attivo. Si de�nisce
percentuale di cicli di clock a TD2 il rapporto tra Cycles_td2 con Cycles_core: tale
rapporto indica la percentuale del tempo in cui un entrambi i thread hardware erano
attivi. Moltiplicando questo valore per 2 e sommandolo alla percentuale di cicli a
TD1 si ottiene il valore medio di TD per il core �sico. In formula:
ATD =Cycles_td1Cycles_core
+ 2 ∗ Cycles_td2Cycles_core
(3.8)
3.3.2 Core Busy Time (CBT)
Con Core Busy Time (CBT) si de�nisce la percentuale di tempo di residenza del
core �sico o logico nello stato attivo C0. Viene usato quindi come sinonimo della
metrica di utilizzo tradizionale (o CPU time). Il CBT è calcolato come rapporto
tra i cicli di clock a frequenza di riferimento (TSC) trascorsi dal core nello stato
attivo C0 (Cycles_ref_thread1 o Cycles_ref_thread2) con il valore della frequenza
di riferimento (TSC). Tale frequenza viene ottenuta moltiplicando il Base Operating
Ratio con la Bus Clock Frequency (BCLK) del processore: de�niamo tale grandezza
CPU_BASE_OPERATING_FREQUENCY. In formula:
CPU_BASE_OPERATING_FREQUENCY = BaseOperatingRatio∗BCLK (3.9)
CBT_thread1 =Cycles_ref_thread1
CPU_BASE_OPERATING_FREQUENCY(3.10)
Calcolando la media dei CBT dei core si ottiene il CBT medio dell'intero sistema,
che è identico al valore di utilizzo tradizionale ottenuto da tool come top e sar.
3.3.3 Instructions per Cycle (IPC)
La metrica di IPC è stata già de�nita nella Sezione 3.1.2. L'IPC di un thread
hardware (core logico) viene calcolato come rapporto tra il numero di istruzioni
ritirate dal thread (Instr_thread1 o Instr_thread2) e il numero di cicli di clock
trascorsi dal thread nello stato attivo C0 (Cycles_thread1 o Cycles_thread2). In
58
3.3. Calcolare altre metriche con i PC
formula l'esempio per il thread numero zero:
IPC_thread0 =Instr_thread0Cycles_thread0
(3.11)
Si sottolinea come questo valore non rappresenti l'IPC di un core �sico. La stima
e�ettuata dal modello (si veda Sezione 3.1.3) riporta infatti i valori degli IPC dei
core �sici (e non dei core logici) utilizzando i dati raccolti a basso carico. Ne viene
poi fatta la media per ottenere un unico valore dell'IPC relativo a tutti i core �sici
del sistema. Per poter veri�care l'a�dabilità e la bontà di questa stima è necessario
poterla paragonare con il valore relativo alla media degli IPC dei core �sici ottenuti
dai dati misurati ad alto carico. Viene quindi de�nito l'IPC di un core �sico come
rapporto tra la somma delle istruzioni dei suoi thread hardware e il numero di cicli di
clock trascorsi dal core �sico in cui almeno uno dei due thread era nello stato attivo
C0. In formula l'esempio per il core numero zero:
IPC_core0 =Instr_thread0+ Instr_thread1
Cycles_core0(3.12)
Viene quindi calcolata la media degli IPC dei core �sici per ottenere l'IPC relativo a
tutti i core �sici del sistema. Si può quindi confrontare il valore ottenuto con quello
stimato dal modello per veri�care quanto sia aderente alla realtà la stima che viene
e�ettuata.
3.3.4 Active Frequency (AFREQ)
Quando si monitorano le performance dei core è usuale anche veri�care la fre-
quenza a cui essi stanno lavorando, chiamata Active Frequency (AFREQ). Tale va-
lore è paragonabile con quello riportato dal tool turbostat (si veda la Sezione 1.3.3).
L'AFREQ di un core logico, o thread hardware, è calcolata come prodotto tra la
CPU_BASE_OPERATING_FREQUENCY e il rapporto tra il numero di cicli di
clock in cui il thread era nello stato attivo C0 e il numero di cicli di clock a frequenza
di riferimento (TSC) in cui il thread era nello stato attivo C0. In formula l'esempio
per il thread numero zero:
AFREQ_thread0 =
Cycles_thread0Cycles_ref_thread0
∗ CPU_BASE_OPERATING_FREQUENCY (3.13)
Calcolando la media degli AFREQ di ogni core logico si ottengono sia l'AFREQ
medio del core �sico sia l'AFREQ medio dell'intero sistema, che permette quindi di
avere un'idea della frequenza media di funzionamento dei core del sistema.
59
Capitolo 4
MTperf
Per supportare le operazioni di raccolta e analisi dei dati è stata sviluppata una
suite di tool in Python chiamata MTperf. Questi tool sono scaricabili liberamente
da internet (si veda [18,19]). La suite si compone di tre tool.
Si danno alcune de�nizioni preliminari relative a come viene strutturato un
esperimento eseguito tramite un benchmark:
� Run: si de�nisce �run� un'esecuzione del benchmark caratterizzata da una
determinata con�gurazione, con particolare attenzione alla quantità di carico
che si vuole applicare sul sistema.
� Test: si de�nisce �test� una serie consecutiva di run. Nell'ambito dell'esecu-
zione di un benchmark, si è deciso di comporre un test da una serie di dieci
run consecutive a carico crescente. Viene anche detto �scala del benchmark�,
dove con scala si intende il fatto che ad ogni run il carico applicato sul sistema
aumenta. Infatti si sono tarate le run in modo che la prima applichi un carico
basso sul sistema (per avere un utilizzo tradizionale del processore di circa il
10%), mentre le successive run applichino un carico sempre maggiore. La deci-
ma e ultima run del test dovrebbe portare il sistema all'uso massimo delle sue
risorse limitatamente alle caratteristiche del benchmark (idealmente al 100%
di utilizzo tradizionale del processore).
� Esperimento: si de�nisce �esperimento� una serie consecutiva di test, eseguiti
in modo da ottenere un maggior numero di dati statistici. Le con�gurazioni
delle run non vengono alterate tra un test e il successivo, in modo che la scala
del benchmark applichi gradualmente lo stesso carico in tutti i test. Usualmente
un esperimento è composto da dieci test.
60
4.1. LaunchCollectors.py
4.1 LaunchCollectors.py
Questo tool esegue la raccolta dei performance counters e di tutte le informazioni
utili relative al processore e al sistema operativo. I dati che vengono raccolti tramite
chiamate a programmi del sistema operativo sono stati presentati nella Sezione 3.2.
Al tool non interessa se sul sistema sia in esecuzione un applicativo di cui si
vogliono monitorare le prestazioni oppure sia in esecuzione un esperimento trami-
te l'uso di un benchmark. Sarà compito dell'utente con�gurare successivamente i
tool Main.py e Main-live.py con i parametri corretti. Nel caso dell'esecuzione di un
benchmark bisogna almeno assicurarsi che la durata del monitoraggio (successiva-
mente determinata dai parametri interval e count) sia uguale o maggiore al tempo
di esecuzione totale dell'esperimento.
4.1.1 Operazioni preliminari
LaunchCollectors.py necessita che sul sistema operativo Linux siano installati i
tool lscpu e rdmsr. I tool vengono lanciati come utente privilegiato tramite sudo e
pertanto è necessario che nel sistema sia possibile eseguire i tool con diritti di root.
Il tool considera che sul sistema sia installato l'Intel P-State driver in quanto va
a leggerne un �le di con�gurazione. Il driver ACPI non è supportato in quanto si
utilizzano le tecnologie più recenti quali il driver Intel.
Il tool si basa sulla lettura di MSR tramite il programma rdmsr. Architetture su
cui non sono presenti gli MSR non possono essere analizzate dal tool. I registri MSR
che vengono letti di default sono lo 0xCEh e lo 0x1ADh. Tali registri potrebbero
non essere i medesimi su architetture di�erenti e pertanto è necessario modi�carli
appropriatamente all'interno del tool (si veda la Sezione 3.2.2).
4.1.2 Input
Gli argomenti che il tool riceve in ingresso sono:
� interval: numero intero che indica la lunghezza dell'intervallo di misurazione
di ocperf e sar in secondi.
� count: numero intero che indica quante volte ocperf e sar devono raccogliere
i dati dal sistema. La durata complessiva del monitoraggio del sistema è data
dal prodotto di count con interval.
� pmutoolsdirpath: stringa che indica il path alla directory dei pmu-tools, che
contiene il tool ocperf.
� reportdirpath: stringa che indica il path alla directory dove si vuole che il
tool salvi i �le di report.
61
4.1. LaunchCollectors.py
Listato 4.1: Lettura di alcune informazioni di sistema tramite LaunchCollectors.py.
1 subprocess.call('echo "BaseFrequency;`lscpu | grep -oP "
Model name :.+\K([0 -9]+\.[0 -9]+) "`;"', stdout=sysFile ,
shell=True)
2 subprocess.call('echo "BaseOperatingRatio;`sudo rdmsr 0xce
-f 15:8 -d`;"', stdout=sysFile , shell=True)
3 subprocess.call('echo "CPUMaxMHz;`lscpu | grep -oP "CPU max
MHz:.+ \K([0 -9]+ ,[0 -9]+)" | sed "s/ ,/\./" `;"', stdout=
sysFile , shell=True)
4 subprocess.call('echo "TurboBoost;`cat /sys/devices/system/
cpu/intel_pstate/no_turbo `;"', stdout=sysFile , shell=
True)
5 subprocess.call('echo "TurboRatioLimit1Core;`sudo rdmsr 0
x1ad -f 7:0 -d`;"', stdout=sysFile , shell=True)
4.1.3 Elaborazione
LaunchCollectors.py invoca dei sottoprocessi che raccolgono le informazioni sulle
caratteristiche del processore e del sistema operativo. Tali dati vengono salvati nel
�le sysCon�g.csv all'interno della directory indicata dall'utente. Nel Listato 4.1 uno
spaccato delle chiamate e�ettuate dal tool.
Successivamente LaunchCollectors.py fa partire il monitoring del sistema tramite
i tool ocperf e sar. Ocperf si occupa di raccogliere i PC di interesse (tramite gli eventi
già citati instructions, cpu_clk_unhalted.thread, cpu_clk_unhalted.thread_any e
cpu_clk_unhalted.ref_tsc), mentre sar monitora l'utilizzo tradizionale del proces-
sore. La fase di monitoring ha una durata complessiva in secondi pari al prodotto
tra interval e count. I �le di report dei tool verranno salvati nella directory indicata
dall'utente.
Terminato il periodo di monitoring viene convertito il �le di output di sar in
formato csv, vengono cambiati i permessi dei �le e il tool termina.
4.1.4 Output
Il tool salva nella directory di output fornita i seguenti �le di report:
� perf.csv: report in formato csv del tool ocperf.
� sar.log: report in formato binario del tool sar. Può essere letto da sar stesso
o dal tool sadf.
� sar.csv: report in formato csv del tool sar.
� sysCon�g.csv: report in formato csv contenente le informazioni del processore
e del sistema.
Questi �le possono essere utilizzati per un'analisi manuale tramite fogli di calcolo
tradizionali, oppure possono essere elaborati dai tool Main.py e Main-live.py.
62
4.2. Main.py:
Report numericoGrafici
SarPerf
Workload ReportSystem Config
[PCM]
Data_collector
Raccolta dati dal SUTdurante l'intervallo del workload
Main
Parsing dei file di reportSalvataggio dei dataset
Aggregazione dei datasetCalcolo di media, stdev, max
Stima del max IPC e delle istruzioniCalcolo della ProductivityCalcolo Core Busy Time
Calcolo Average Thread DensityCalcolo Average Active Frequency
Stampa grafici richiesti
Figura 4.1: Flusso di lavoro dei tool di MTperf.
4.2 Main.py:
Questo tool esegue il parsing del �le di report del benchmark (o dell'applicativo
il cui output si conforma allo standard del �le di report) e utilizza questi dati per
e�ettuare l'aggregazione, l'analisi e l'elaborazione dei dati raccolti da tool come sar,
ocperf e PCM. Il tool poi calcola la metrica di productivity considerando un nume-
ro di run del benchmark a basso carico deciso dall'utente e ne stima l'andamento
all'aumentare del throughput. Questo valore viene quindi confrontato con i valori
che si ottengono dal calcolo della productivity nelle run ad alto carico per veri�care
l'a�dabilità e la precisione della stima fatta a basso carico. Il tool inoltre riporta
anche l'utilizzo tradizionale e calcola le altre metriche descritte. Viene restituito in
output un �le numerico in cui sono riportate queste metriche, oltre a stampare gra�ci
per un'analisi visuale.
In Figura 4.1 viene riportato uno schema di funzionamento dei tool nel caso di
studio di un sistema sul quale viene eseguito un workload (benchmark o applicativo).
4.2.1 Operazioni preliminari
Prima di poter lanciare Main.py bisogna eseguire alcune operazioni preliminari:
1. De�nire una directory in cui sono presenti i �le di report. Il path di tale direc-
tory sarà utilizzato come argomento del tool. All'interno della directory devono
essere presenti i �le di report denominati sar.csv, perf.csv, benchmark.csv ed
opzionalmente i �le sysCon�g.csv e pcm.csv.
2. Se il �le sysCon�g.csv è presente nella directory e viene indicato l'argomento
-syscon�g al lancio del tool, allora il tool si occupa di settare in automatico i
63
4.2. Main.py:
parametri relativi alla con�gurazione del sistema. Se il �le non è presente e
non viene indicato l'argomento -syscon�g, allora i parametri di con�gurazione
del sistema devono essere modi�cati a mano dentro alla funzione set_manual()
del �le con�g/SUTcon�g.py.
3. Se il �le pcm.csv è presente nella directory e viene indicato l'argomento -pcm
al lancio del tool, allora il tool si occupa di elaborare anche i dati di report di
PCM contenuti in questo �le. Se non viene indicato l'argomento -pcm allora
tale �le non viene considerato.
4. Il tool utilizza alcuni parametri de�niti nel �le con�g/BenchmarkAnalysisCon-
�g.py, che vengono descritti di seguito:
� NUM_SAMPLES: valore intero che indica il numero di run, a partire
dalla prima di ogni test, da considerare per eseguire la regressione lineare
multivariata. Solitamente si setta pari a quattro, in modo da considerare
solo le run a basso carico.
� NUM_RUNS: valore intero che indica il numero di run in un test,
usualmente è settato pari a dieci.
� NUM_TESTS: valore intero che indica il numero di test dell'esperimento,
usualmente è settato pari a dieci.
� TITLE: stringa che indica il titolo da utilizzare all'interno dei �le di
output.
� START_RUN: valore intero che indica il numero della prima run di un
test da cui si vuole partire a calcolare l'IPC. Solitamente è settato pari a
uno.
� END_RUN: valore intero che indica il numero dell'ultima run di un test
�no a cui si vuole calcolare l'IPC. Solitamente è settato pari a dieci.
� X_MAX_PADDING: valore intero che serve per prolungare la retta
di regressione all'interno dei gra�ci in output. Deve essere impostato
adeguatamente secondo il throughput del benchmark o dell'applicativo.
4.2.2 Input
Gli argomenti che il tool riceve in ingresso sono:
� benchmarkdirpath: stringa che indica il path alla directory dove sono pre-
senti le cartelle dei vari esperimenti e il �le eventuale sysCon�g.csv. Ogni
cartella contiene i �le di report di quell'esperimento.
� reportdirpath: stringa che indica il path alla directory dove si vuole che il
tool salvi i �le di report.
64
4.2. Main.py:
� -pcm: parametro opzionale che indica che si vuole utilizzare il �le pcm.csv di
ogni esperimento.
� -syscon�g: parametro opzionale che indica che si vuole utilizzare il �le
sysCon�g.csv.
4.2.3 Elaborazione
Si descrivono di seguito i passaggi che il tool esegue.
4.2.3.1 Importazione dei dati
Come prima operazione il tool si occupa di de�nire le costanti che descrivono
le speci�che del sistema sotto test. Tali costanti vengono assegnate utilizzando il
�le sysCon�g.csv se speci�cato dall'argomento opzionale, oppure viene invocata la
funzione set_manual() che imposta i parametri che si sono con�gurati manualmente
all'interno del codice.
In particolare si evidenzia che tramite il Model del processore (attualmente sono
supportate le famiglie Nehalem, Sandy Bridge, Ivy Bridge e Haswell) viene indivi-
duata la CPU_BUS_CLOCK_FREQUENCY (BCLK). Si possono ora ottenere le
varie frequenze che caratterizzano il processore (Listato 4.2):
� CPU_BASE_OPERATING_FREQUENCY: prodotto del Base Ope-
rating Ratio con la CPU_BUS_CLOCK_FREQUENCY. È la frequenza di
riferimento del processore (TSC).
� CPU_BASE_FREQUENCY: prodotto della Base Frequency con 109. È
la frequenza pubblicizzata del processore.
� CPU_MAX_FREQUENCY_ALL_CORES_BUSY: prodotto del
Turbo Ratio Limit 4 Cores (ottenuto dall'MSR_TURBO_RATIO_LIMIT)
con la CPU_BUS_CLOCK_FREQUENCY. Indica la frequenza massima do-
vuta al turbo boost nel caso in cui tutti e quattro i core �sici del processo-
re siano nello stato attivo C0. È stata chiamata Core_max_frequency nella
Formula 3.5. Nel caso in cui il turbo boost non sia attivo, viene posta pari
alla CPU_BASE_FREQUENCY in quanto questa risulta essere la massima
frequenza del processore senza il turbo boost.
Vengono quindi importati tutti i dati dei �le di report forniti in ingresso: ne viene
e�ettuato il parsing tramite funzioni speci�che per ogni tipologia di �le e vengono
creati degli oggetti dataframe contenenti questi dati. I dataframe vengono quindi
salvati in apposite tabelle di un database SQLite.
65
4.2. Main.py:
Listato 4.2: Calcolo delle frequenze del processore.
if system_config['Model '] == 60 or system_config['Model ']
== 63 or system_config['Model'] == 69 or system_config['
Model '] == 70:
self.CPU_BUS_CLOCK_FREQUENCY = 100000000 # BCLK for
Intel Haswell Architecture
elif system_config['Model '] == 42 or system_config['Model ']
== 45 or system_config['Model'] == 58:
self.CPU_BUS_CLOCK_FREQUENCY = 100000000 # BCLK for
Intel SandyBridge and IvyBridge Architectures
elif system_config['Model '] == 26 or system_config['Model ']
== 30 or system_config['Model'] == 46:
self.CPU_BUS_CLOCK_FREQUENCY = 133330000 # BCLK for
Nehalem Architecture
self.CPU_BASE_OPERATING_FREQUENCY = system_config['
BaseOperatingRatio '] * self.CPU_BUS_CLOCK_FREQUENCY
self.CPU_BASE_FREQUENCY = system_config['BaseFrequency '] *
1000000000
if int(system_config['TurboBoost ']) == 0: # TB ON
self.CPU_MAX_FREQUENCY_ALL_CORES_BUSY = system_config['
TurboRatioLimit4Cores '] * self.
CPU_BUS_CLOCK_FREQUENCY
else: # TB OFF
self.CPU_MAX_FREQUENCY_ALL_CORES_BUSY = self.
CPU_BASE_FREQUENCY
4.2.3.2 Creazione dei dataset
Si procede quindi alla selezione ed aggregazione delle metriche presenti sul data-
base. Vengono presi i timestamp di inizio e �ne di ogni run e si esegue una query
sul database che selezioni i dati misurati in quell'intervallo temporale. Tali dati (i
PC raccolti da ocperf, le statistiche di sar ed eventualmente quelle di PCM) vengo-
no quindi manipolati per ottenerne media, deviazione standard e massimo relativo
all'intervallo. Tali dati vengono quindi salvati su appositi �le di report in formato
csv. Viene così creato un oggetto dataset che contiene tutti i dati appena aggregati,
oltre ai dati relativi alle run dello speci�co esperimento.
4.2.3.3 Stima della productivity
I dati presenti in ciascun dataset vengono quindi utilizzati per calcolare la metrica
di productivity e stimare gli IPC dei core come è stato descritto nella Sezione 3.1.3.
Nello speci�co vengono utilizzati i PC raccolti da ocperf di cui è stata calcolata la
media. Si ricavano quindi i cicli di clock a TD2, successivamente i cicli di clock a
TD1 e in�ne le istruzioni ritirate. In seguito viene e�ettuata la regressione lineare
66
4.2. Main.py:
multivariata per stimare i valori massimi degli IPC quando il sistema è a carico
massimo, considerando il numero di capioni de�niti dall'utente tramite il parametro
NUM_SAMPLES (Listato 4.3).
Grazie alla stima dell'IPC a TD1 e a TD2 è possibile calcolare le istruzioni massi-
me ritirabili come prodotto dell'IPC a TD2 (nel caso di HT attivo, altrimenti IPC a
TD1) per la CPU_MAX_FREQUENCY_ALL_CORES_BUSY. La productivity
di un core �sico viene quindi calcolata come rapporto tra le sue istruzioni ritirate
e le istruzioni massime ritirabili. In�ne la productivity del sistema viene calcolata
come media tra le productivity dei core �sici.
4.2.3.4 Altre metriche
Utilizzando sempre i dati medi ricavati da ocperf e da sar, vengono calcolate
altre metriche quali l'ATD, il CBT, l'IPC reale dei core �sici e l'AFREQ (descritte
nella Sezione 3.3). Si riporta come esempio la funzione che calcola le AFREQ medie
dei core �sici del sistema (Listato 4.4). In�ne viene generato il �le LRModel.csv
contenente tutte le metriche calcolate.
4.2.3.5 Gra�ci
Per permettere un'analisi visiva dei dati è possibile esportare dei gra�ci che metta-
no a confronto le diverse metriche ottenute degli esperimenti presi in considerazione.
In particolare è possibile esportare gra�ci che paragonano:
� Utilizzo tradizionale (o CBT) contro throughput
� Productivity contro throughput
� Response time contro utilizzo tradizionale
� Response time contro productivity
� ATD contro throughput
� AFREQ contro throughput
� Utilizzo tradizionale ed AFREQ contro throughput
Grazie alla stampa delle regressioni lineari sui primi campioni de�niti dall'utente è
immediatamente visibile veri�care se i valori ad alto carico confermano l'andamento
previsto dalla retta di regressione. Tutti i gra�ci che vengono rapportati al throu-
ghput evidenziano quindi come si comportano le performance del sistema al crescere
del workload che gli si somministra.
Nel caso del gra�co che rapporta utilizzo tradizionale e throughput è comune
trovare un comportamento non lineare come quello già mostrato in Figura 2.1. Il
67
4.2. Main.py:
gra�co che mette a confronto la productivity e il throughput invece è lo strumento
innovativo per studiare le performance di un sistema al crescere del workload. Esso
mostra quale sia la previsione fatta dal modello e la retta di tendenza calcolata
a basso carico. Il gra�co che rapporta response time contro utilizzo tradizionale
dovrebbe evidenziare un comportamento cosiddetto a �mazza da hockey�, con i
tempi di risposta che si mantengono stabili �no a circa l'80% e successivamente
salgono molto rapidamente.
4.2.4 Output
Main.py restituisce in output una cartella che contiene i gra�ci che riportano l'a-
nalisi globale di tutti gli esperimenti e tante sottocartelle quanti sono gli esperimenti
considerati in input. Ogni sottocartella contiene il �le LRModel.csv che riporta tutte
le metriche calcolate relativamente a quell'esperimento, oltre ai �le di report di sar,
ocperf ed eventualmente pcm. Le metriche contenute nel �le LRModel.csv sono:
� Sys_mean_productivity: la productivity media del sistema.
� Sys_mean_atd: l'ATD media del sistema.
� Sys_mean_cbt: il CBT medio misurato sul sistema (corrispondente all'utilizzo
tradizionale).
� Sys_mean_utilization: l'utilizzo tradizionale del sistema ottenuto da sar
(corrispondente al CBT).
� Sys_mean_AFREQ: la frequenza attiva media misurata sul sistema.
� Sys_mean_real_IPC: l'IPC medio dei core �sici misurato sul sistema.
Dipende dalle costanti START_RUN ed END_RUN.
� Sys_mean_estimated_IPC_TDx: l'IPC massimo dei core �sici del sistema
stimato dal modello. È pari alla media degli IPC stimati dei singoli core. Il
valore di �x� viene impostato a seconda che l'HT sia attivo o no. Se è attivo
allora nella colonna si mostra l'IPC relativo a TD2 poichè il sistema a regime
idealmente fa lavorare entrambi i thread. Se non è attivo allora nella colonna
si mostra l'IPC relativo a TD1 in quanto senza l'HT un solo thread è attivo.
� Sx-Cy-EST-IPC-TDz: l'IPC massimo stimato dal modello relativo al core �sico
�y� della socket �x�. Il valore di �z� viene impostato a seconda che l'HT sia
attivo o no. Se l'HT è attivo allora si mostrano due colonne con il valore di
IPC stimato per TD1 e TD2. Se l'HT non è attivo si mostra una sola colonna
con il valore di IPC stimato per TD1.
68
4.3. Main-live.py:
� Sx-Cy-REAL-IPC-TDz: l'IPC medio misurato sul sistema relativo al core �sico
�y� della socket �x�. Dipende dalle costanti START_RUN ed END_RUN. Il
valore di �z� viene impostato a seconda che l'HT sia attivo o no. Se è attivo
allora nella colonna si mostra l'IPC relativo a TD2 poichè il sistema a regime
idealmente fa lavorare entrambi i thread. Se non è attivo allora nella colonna
si mostra l'IPC relativo a TD1 in quanto senza l'HT un solo thread è attivo.
4.3 Main-live.py:
Questo tool ha un funzionamento simile a Main.py, ma è stato pensato per lavo-
rare con un solo �le di report di ocperf e di sar in ingresso. Al tool viene fornito un
intervallo in cui suddividere il periodo di monitoring e per ogni intervallo vengono
calcolate le metriche usuali. Questo tool è pensato per analizzare un sistema di cui
non si hanno �le di report dell'applicativo, ma di cui si e�ettuano solo le misurazioni
delle performance.
4.3.1 Operazioni preliminari
Prima di poter lanciare Main-live.py bisogna eseguire alcune operazioni
preliminari:
1. De�nire una directory in cui sono presenti i �le di report. Il path di tale direc-
tory sarà utilizzato come argomento del tool. All'interno della directory devono
essere presenti i �le di report denominati sar.csv, perf.csv ed opzionalmente il
�le sysCon�g.csv.
2. Se il �le sysCon�g.csv è presente nella directory e viene indicato l'argomento
-syscon�g al lancio del tool, allora il tool si occupa di settare in automatico i
parametri relativi alla con�gurazione del sistema. Se il �le non è presente e
non viene indicato l'argomento -syscon�g, allora i parametri di con�gurazione
del sistema devono essere modi�cati a mano dentro alla funzione set_manual()
del �le con�g/SUTcon�g.py.
3. Il tool utilizza alcuni parametri de�niti nel �le con�g/BenchmarkAnalysisCon-
�g.py. In particolare bisogna impostare i seguenti parametri:
� NUM_TESTS = 1, indica che i dati raccolti dal sistema sono appartenenti
a un solo test, in quanto la misurazione viene e�ettuata su un periodo
temporale arbitrario.
� START_RUN = 1, indica che si deve iniziare a calcolare l'IPC a partire
dalla prima run del test.
� END_RUN = 1, indica che si deve calcolare l'IPC �no alla prima run del
test. Coincide con START_RUN in quanto nel test si ha una sola run.
69
4.3. Main-live.py:
4.3.2 Input
Gli argomenti che il tool riceve in ingresso sono:
� inputdirpath: stringa che indica il path alla directory dove sono presenti i
�le di report.
� interval: numero intero che indica quanto dura in secondi l'intervallo di analisi
dei dati.
� -syscon�g: parametro opzionale che indica che si vuole utilizzare il �le
sysCon�g.csv.
4.3.3 Elaborazione
Il tool ha un funzionamento simile a Main.py. Di�erisce per il fatto che esso non
utilizza il �le di report del benchmark o dell'applicativo per sezionare il periodo di
misurazione in intervalli su cui e�ettuare i calcoli, ma utilizza il valore di interval
per fare tale operazione. Non avendo nemmeno un �le di report di un benchmark
o un'applicazione in ingresso, non utilizza dati quali il throughput e il response
time. Per fare la previsione dell'andamento, la regressione lineare multivariata viene
eseguita considerando i campioni raccolti nella nell'intervallo temporale che si sta
analizzando.
4.3.4 Output
Il tool riporta sullo stdout l'output dell'elaborazione, ovvero le metriche che ven-
gono calcolate per ogni intervallo temporale (ad eccezione del primo) durante il
periodo di misurazione. Tali metriche sono:
� Sys Mean Estimated IPC_TD1: l'IPC a TD1 massimo dei core �sici del sistema
stimato dal modello. È pari alla media degli IPC stimati dei singoli core.
Se l'HT è attivo non si mostra alcun valore in quanto bisogna prendere in
considerazione la colonna successiva relativa all'IPC a TD2.
� Sys Mean Estimated IPC_TD2: l'IPC a TD2 massimo dei core �sici del sistema
stimato dal modello. È pari alla media degli IPC stimati dei singoli core. Se
l'HT non è attivo non si mostra alcun valore in quanto bisogna prendere in
considerazione la colonna precedente relativa all'IPC a TD1.
� S0-C0 Instructions_max: numero massimo di istruzioni stimate che il core zero
della socket zero può ritirare ad ogni ciclo di clock.
� Sys Productivity: la productivity media del sistema.
70
4.3. Main-live.py:
� Sys Utilization (Sar): l'utilizzo tradizionale del sistema ottenuto da sar
(corrispondente al CBT).
� Sys Avg Thread Density: l'ATD media del sistema.
� Sys Mean Active Frequency: la frequenza attiva media misurata sul sistema.
71
4.3. Main-live.py:
Listato 4.3: Stima degli IPC con Regressione Lineare Multivariata
# For each Socket and for each Core i in Socket , compute
IPC_td1 and IPC_td2 with Multivariate Linear Regression
def estimate_IPCs(self , Ci_unhalted_clk_td1 , Ci_instr ,
Ci_unhalted_clk_td2=None):
result = {}
for s in range(self.my_sut_config.CPU_SOCKETS):
for c in range(self.my_sut_config.
CPU_PHYSICAL_CORES_PER_SOCKET):
# y = one element per row [Ci_istr], getting only
the first NUM_SAMPLES elements for each NUM_RUNS
y = Ci_instr['S' + str(s) + '-C' + str(c)]. reshape
(-1, bac.NUM_RUNS)[:,:bac.NUM_SAMPLES ]. reshape
(-1, 1)
if Ci_unhalted_clk_td2 == None:
# Reshape to get only the first NUM_SAMPLES
elements
clk_td1_column = Ci_unhalted_clk_td1['S' + str(
s) + '-C' + str(c)]. reshape(-1, bac.NUM_RUNS
)[:,:bac.NUM_SAMPLES ]. reshape(-1, 1)
X = [i for i in clk_td1_column]
else:
# Reshape to get only the first NUM_SAMPLES
elements
clk_td1_column = Ci_unhalted_clk_td1['S' + str(
s) + '-C' + str(c)]. reshape(-1, bac.NUM_RUNS
)[:,:bac.NUM_SAMPLES ]. reshape(-1, 1)
clk_td2_column = Ci_unhalted_clk_td2['S' + str(
s) + '-C' + str(c)]. reshape(-1, bac.NUM_RUNS
)[:,:bac.NUM_SAMPLES ]. reshape(-1, 1)
# X = two elems per row [Ci_unhalted_clk_td1 ,
Ci_unhalted_clk_td2]
X = np.column_stack (( clk_td1_column ,
clk_td2_column))
regr = lm.LinearRegression(fit_intercept=False)
regr.fit(X, y)
result['S' + str(s) + '-C' + str(c)] = {'model' :
regr , 'coefficients ': regr.coef_}
return result
72
4.3. Main-live.py:
Listato 4.4: Stima delle AFREQ dei core �sici
# Compute the mean active frequencies for each core
def compute_mean_active_frequencies(self , dataset):
result = {}
for s in range(self.my_sut_config.CPU_SOCKETS):
for c in range(self.my_sut_config.
CPU_PHYSICAL_CORES_PER_SOCKET):
tmp_freq = pd.Series ()
tmp_ref_tsc = pd.Series ()
for j in self.my_sut_config.
CPU_PHYSICAL_TO_LOGICAL_CORES_MAPPING['CPU' +
str(c)]:
if len(tmp_freq) == 0 and len(tmp_ref_tsc) ==
0:
tmp_freq = tmp_freq.append(dataset['perf -
stats ']['mean']['CPU' + str(j) + '
_cpu_clk_unhalted_thread '])
tmp_ref_tsc = tmp_ref_tsc.append(dataset['
perf -stats']['mean']['CPU' + str(j) + '
_cpu_clk_unhalted_ref_tsc '])
else:
tmp_freq = tmp_freq.add(dataset['perf -stats
']['mean']['CPU' + str(j) + '
_cpu_clk_unhalted_thread '])
tmp_ref_tsc = tmp_ref_tsc.add(dataset['perf
-stats ']['mean']['CPU' + str(j) + '
_cpu_clk_unhalted_ref_tsc '])
# Divide by number of threads per core
tmp_freq = tmp_freq.div(self.my_sut_config.
CPU_THREADS_PER_CORE)
tmp_ref_tsc = tmp_ref_tsc.div(self.my_sut_config.
CPU_THREADS_PER_CORE)
result['S' + str(s) + '-C' + str(c)] = tmp_freq.div
(tmp_ref_tsc).multiply(self.my_sut_config.
CPU_BASE_OPERATING_FREQUENCY)
return result
73
Capitolo 5
Validazione sperimentale
5.1 Sistema sotto test
Un sistema sotto test (System Under Test, in breve SUT) è una macchina sul-
la quale viene eseguito un workload e di cui vengono monitorate le performance.
Dopo la raccolta dei dati vengono eseguite le analisi tradizionali di previsione delle
performance, oltre all'applicazione del modello proposto. Gli esperimenti sono stati
eseguiti su una macchina a disposizione che presenta tutte le tecnologie descritte in
Sezione 1.1.
La macchina è un computer portatile Asus modello K56CB, indicato in seguito
come SUT. Si riportano le speci�che tecniche di interesse (per ulteriori dettagli si
veda [1]):
� CPU: Intel Core i7-3537U
� Scheda Gra�ca: NVIDIA GeForce GT 740M 4 GB DDR3
� Hard Disk: 1 TB SATA 5400 rpm
� RAM: 8 GB DDR3-1600
� Sistema Operativo: Ubuntu 15.04 - 64 bit
In particolare la CPU, modello Intel Core i7-3537U di terza generazione (Ivy Bridge),
ha le seguenti caratteristiche (per ulteriori dettagli si veda [22]):
� Numero di Core: 2
� Numero di Thread: 4 (grazie a Intel Hyper-Threading)
� Processor Base Frequency: 2.00 GHz
� Max Turbo Frequency (Intel Turbo Boost 2.0): 3.10 GHz con un core attivo,
2.90 GHz con due core attivi
74
5.2. Test cases
� Thermal Design Power: 17 W
� Temperatura massima: 105 °C
� L1 Cache: 2 x (32 KB + 32 KB)
� L2 Cache: 2 x 256 KB
� L3 Cache: 4096 KB shared
� Enhanced Intel SpeedStep Technology con Idle States
La frequenza di riferimento (TSC) viene rilevata da turbostat pari a 2.5 GHz.
5.2 Test cases
Poichè sul SUT sono presenti di�erenti tecnologie è necessario avere ben chiaro
in quale con�gurazione del SUT si stia eseguendo un esperimento. In particolare
le tecnologie che possono avere un ruolo chiave nel determinare le performance del
sistema sono:
� Hyper-Threading attivo o non attivo
� Governor powersave o performance
� Turbo Boost attivo o non attivo
Possiamo quindi disegnare un albero di test cases (Figura 5.1) che declina le
con�gurazioni possibili del SUT.
Hyper-Threading
Governor
Turbo Boost
Governor
Turbo Boost Turbo BoostTurbo Boost
ON
ON ON ONON
OFF
OFFOFF OFFOFF
PerformancePerformance PowersavePowersave
TC1 TC2 TC3 TC5 TC7TC6TC4 TC8
Figura 5.1: Albero dei possibili test cases.
In particolare si evidenziano le seguenti con�gurazioni:
75
5.2. Test cases
� TC1: HT on, governor powersave e TB on. Rappresenta il test case di base in
quanto è la con�gurazione standard in cui ogni sistema moderno è usualmente
con�gurato di default.
� TC3: HT on, governor performance e TB on. Questa con�gurazione può
essere trovata in sistemi che vogliono dare priorità alle performance più che al
risparmio energetico.
� TC6: HT o�, governor powersave e TB o�. È la con�gurazione meno perfor-
mante in quanto non usufruisce dell'Hyper-Threading e del Turbo Boost, oltre
a utilizzare la frequenza più bassa possibile grazie al governor powersave.
� TC8: HT o�, governor performance e TB o�. È la con�gurazione che più si av-
vicina ad un sistema tradizionale, in quanto non è attivo nè l'Hyper-Threading
nè il Turbo Boost, mentre il governor performance fa sì che la frequenza di lavo-
ro sia sempre �ssata (come era nei processori senza dynamic frequency scaling)
pari al massimo consentito dall'architettura.
Verranno esplorate, a seconda dei risultati che si vogliono ottenere, alcune delle
con�gurazioni presenti nell'albero. Volta per volta verrà sempre descritta la con-
�gurazione del SUT adottata per eseguire i vari esperimenti. Per ogni test case
analizzato viene eseguito un esperimento articolato in dieci scale del benchmark. I
dati raccolti hanno evidenziato come le performance del sistema si siano comportate
in modo coerente e stabile ad ogni esecuzione dell'esperimento. Si sono poi utilizzati
questi dati per eseguire l'analisi tramite MTperf. I risultati che verranno esposti
sono stati ottenuti considerando i primi quattro campioni di ogni test per eseguire la
regressione lineare. Questo ci permette di essere in una situazione in cui il workload
esercita un carico modesto sul sistema (pari ad un utilizzo tradizionale del 30-40%),
cosa che accade di frequente nella pratica industriale. Spesso accade anche che un
sistema abbia un carico ancora più basso, pari al 10-20% di utilizzo tradizionale. Uno
studio di capacity planning tradizionale può essere e�ettuato anche su un sistema
di questo tipo, benchè l'errore potrà essere ancora più evidente. Su questi dati si
eseguono poi le previsioni dei modelli di utilizzo tradizionale e di productivity. I dati
raccolti a carico più alto servono successivamente come veri�ca del comportamento
reale del sistema rispetto alle stime precedenti.
Negli esperimenti che si descriveranno si vuole veri�care che la productivity possa
risolvere i due problemi principali che sono stati descritti in Sezione 2.3, ovvero il
fatto di considerare l'Hyper-Threading e la variazione di frequenza del processore
all'interno della metrica.
76
5.3. Esperimenti con RUBBoS
5.3 Esperimenti con RUBBoS
In questa sezione si presentano i risultati ottenuti dagli esperimenti eseguiti con
il benchmark RUBBoS, descritto nella Sezione 1.4.1. Benchè RUBBoS sia un ben-
chmark noto ed utilizzato, si sono riscontrati alcuni limiti durante l'installazione e
l'utilizzo. Essendo stato rilasciato già diversi anni fa, questo benchmark utilizza tool
in versioni datate rispetto a quelle attuali e pertanto si sono dovuti eseguire dei roll-
back a tali versioni. Inoltre sono stati corretti anche dei problemi nel codice sorgente
riguardanti la comunicazione tra processi.
Durante l'utilizzo di RUBBoS vi sono state alcune di�coltà nel determinare il
carico massimo applicabile al sistema. Infatti un carico eccessivo faceva bloccare il
sistema (dovuto a limiti della JVM) mentre un carico appena inferiore non permette
di raggiungere un valore di utilizzo tradizionale superiore all'80% circa. Per tale
motivo non si è potuto ottenere un valore di utilizzo del sistema maggiore e pertanto
lo scostamento dell'andamento dell'utilizzo rispetto alla sua retta di previsione sarà
sicuramente apprezzabile, eppure non sarà così accentuato come si potrà
notare negli esperimenti eseguiti con gli altri benchmark. D'altra parte
RUBBoS è stato utilizzato in quanto è un benchmark completo e a�dabile, oltre
al fatto che la sua reportistica fornisce dettagli importanti sull'andamento del test
(throughput, tempo di risposta, gra�ci sull'uso delle risorse dei vari nodi, ecc...).
Per evitare che le letture e le scritture sul database (posto sul disco �sico) fosse
un collo di bottiglia per le operazioni sul processore, si è deciso di spostare il data-
base nella memoria principale. Ciò ha permesso di avere un utilizzo maggiore del
processore e una gestione migliore dei processi del benchmark, in quanto l'attesa
verso l'I/O è stata limitata il più possibile.
5.3.1 Con�gurazione di una run
RUBBoS presenta un �le di con�gurazione articolato attraverso il quale è possibile
impostare i parametri che caratterizzano ciascuna run del benchmark. Nel nostro
caso gli indirizzi del server applicativo, del server ospitante il database e del nodo
che invia le richieste sono coincidenti in quanto si fanno risiedere tutte le componenti
dell'esperimento sulla stessa macchina. Si riportano i parametri più interessanti che
sono stati con�gurati per gli esperimenti che verranno mostrati in seguito:
� workload_number_of_clients_per_node: indica quanti client debbano
essere gestiti da un nodo, ovvero il numero di utenti simulati che vogliono
interagire con l'applicativo. Essi inviano richieste al server, attendono rispo-
sta, pensano e ripartono. Questo valore è il più importante, in quanto esso
determina il workload che sarà sottoposto al sistema.
77
5.3. Esperimenti con RUBBoS
� workload_use_tpcw_think_time: impostato di default a yes, indica che
lo think time dei client è compatibile con quello de�nito da TPC-W (7 secondi).
� workload_up_ramp_time_in_ms: durata della rampa di salita del
benchmark. Usualmente è settato pari a 60 secondi.
� workload_session_run_time_in_ms: durata della session del bench-
mark. Usualmente è settato pari a 180 secondi.
� workload_down_ramp_time_in_ms: durata della rampa di discesa del
benchmark. Usualmente è settato pari a 60 secondi.
� monitoring_program: path di sar (/usr/local/bin/sar). RUBBoS utilizza
la versione 8.0.3 di sysstat.
� monitoring_options: argomenti da passare a sar quando viene invocato da
RUBBoS. Default: -n DEV -n SOCK -rubcw.
� monitoring_sampling_in_seconds: intervallo di campionamento di sar,
default 5 secondi.
Complessivamente quindi una run di RUBBoS dura cinque minuti (uno di rampa
ascendente, tre di session e uno di rampa discendente). Come usuale dalla run
verranno estratti solo i dati corrispondenti ai tre minuti di session, tralasciando il
comportamento del sistema quando viene caricato o scaricato dal workload. Solo
quell'intervallo permette di avere un sistema che si comporta in modo stabile e il cui
workload sia andato a regime.
Ad ogni con�gurazione di test case RUBBoS viene tarato in modo da sfruttare
al massimo le risorse disponibili del SUT.
5.3.2 SUT in con�gurazioni standard
I due esperimenti mostrati di seguito sono ottenuti dal SUT con�gurato nel mo-
do più comune possibile, ovvero con Hyper-Threading attivo e Turbo Boost attivo.
L'unica di�erenza è il fatto che nel primo si imposta il governor a powersave (TC1),
mentre nel secondo a performance (TC3). Questo ci permette di vedere i compor-
tamenti dei sistemi con�gurati in modo standard, ovvero quelle con�gurazioni che
si trovano usualmente abilitate di default sui sistemi odierni. Si potrà quindi va-
lutare l'impatto del governor sulle performance del sistema durante l'esecuzione di
RUBBoS.
5.3.2.1 TC1: Governor powersave
In Figura 5.2 si ha l'andamento dell'utilizzo tradizionale al crescere del through-
put. Come previsto si veri�ca che tale crescita è non lineare: infatti si ha che i valori
78
5.3. Esperimenti con RUBBoS
a carico elevato si discostano dalla stima che viene e�ettuata sui primi quattro cam-
pioni a basso carico. Se si fosse fatta una stima sui primi due campioni (nell'ipotesi
di un sistema con un utilizzo ancora più basso) lo scostamento sarebbe stato decisa-
mente più marcato. L'andamento della productivity rispetto al throughput (Figura
5.3) per lo stesso esperimento invece è caratterizzata da un comportamento lineare.
Come si può notare dai gra�ci, le regressioni hanno una precisione molto di�erente
nel prevedere l'andamento delle rispettive metriche. In Tabella 5.1 sono riportati gli
indici R2 e MAE: il primo indica la bontà del �tting della retta di previsione con
i dati misurati, mentre il secondo indica l'errore medio assoluto dei dati misurati
rispetto al valore indicato dalla regressione. Il modello tradizionale basato sull'U-
tilization Law ha una precisione decisamente bassa nello stimare l'e�ettivo utilizzo
tradizionale ad alto carico. Pertanto eseguire uno studio di previsione delle capacità
basandosi su tale risultato porta inevitabilmente a fornire valori inesatti rispetto a
come realmente si comporterà il sistema. Ad esempio si ha che per un valore di th-
roughput pari a 1500 la stima indica un utilizzo tradizionale di circa il 50%, mentre
in realtà i dati indicano un utilizzo e�ettivo superiore al 60%. La regressione ba-
sata sul modello della productivity invece fornisce valori molto più precisi. Sempre
prendendo a riferimento il throughput pari a 1500, sia la stima sia il valore e�ettivo
indicano una productivity pari al 60%. In questo modo si riesce ad eseguire la stima
della reale capacità elaborativa di un processore in modo molto più accurato rispetto
alla stima basata sull'utilizzo tradizionale.
0 500 1000 1500
Throughput
0
20
40
60
80
100
Uti
lizzo
Tra
dizi
onal
e
Stima dell’Utilizzo Tradizionale (4 campioni)RUBBoS Benchmark
SUT: HT on, TB on, Governor powersave
Utilization LawUtilizzo Tradizionale
Figura 5.2: RUBBoS TC1: analisi di Utilizzo contro Throughput, sistema incon�gurazione standard (governor powersave).
79
5.3. Esperimenti con RUBBoS
0 500 1000 1500
Throughput
0
20
40
60
80
100
Pro
duct
ivit
yStima della Productivity (4 campioni)
RUBBoS BenchmarkSUT: HT on, TB on, Governor powersave
Regressione LineareProductivity
Figura 5.3: RUBBoS TC1: analisi di Productivity contro Throughput, sistema incon�gurazione standard (governor powersave).
Tabella 5.1: RUBBoS TC1: confronto tra gli R2 e i MAE dei modelli basati su Uti-lizzo Tradizionale e Productivity con il sistema in con�gurazione standard (governorpowersave).
Modello R2 MAE
Utilizzo Tradizionale 0,8401 6,0617Productivity 0,9949 0,8236
La Figura 5.4 mostra l'andamento dei tempi di riposta, che segue una crescita
a mazza da hockey. La variabilità dei tempi di risposta ad alto carico è dovuta al
fatto che il benchmark utilizza distribuzioni proprietarie per l'arrivo delle richieste di
lettura e scrittura sull'applicativo, il che può risultare in di�erenti tempi di risposta
a seconda delle condizioni contingenti al run speci�co. Il fatto che i tempi di rispo-
sta siano iniziati a salire vuol dire che il sistema ha iniziato ad accodare richieste
e che quindi non riesce ad elaborare un maggior numero di richieste. Questo com-
portamento indica che per la tale architettura e per il tale applicativo in esecuzione
non è possibile ottenere un throughput maggiore in quanto il sistema sta andando
in saturazione. Questo però non signi�ca che tutte le risorse del processore siano
utilizzate al loro massimo, come mostrano i valori dell'utilizzo tradizionale e della
productivity.
L'andamento dell'Average Thread Density del sistema è visibile in Figura 5.5. Si
nota che il numero medio di thread utilizzati aumenta gradualmente all'aumentare
80
5.3. Esperimenti con RUBBoS
0 20 40 60 80 100
Utilizzo Tradizionale
0
20
40
60
80
100
120
Res
pons
eT
ime
(ms)
Andamento del Response Time rispetto all’Utilizzo TradizionaleRUBBoS Benchmark
SUT: HT on, TB on, Governor powersave
Response Time (ms)
Figura 5.4: RUBBoS TC1: andamento del Response Time rispetto all'Utilizzo,sistema in con�gurazione standard (governor powersave).
del workload sul sistema. Non viene raggiunto il limite di ATD pari a due in quanto
il processore del sistema non sta lavorando al massimo delle proprie capacità. Si nota
come non venga mai usato esclusivamente un thread hardware ma vi sia sempre un
certo grado di parallelismo tra i thread.
Nella Tabella 5.2 sono riportati i risultati aggregati delle dieci run di questo
esperimento. In particolare si evidenzia come il sistema inizi ad utilizzare la frequenza
massima del TB con entrambi i core attivi a partire dalla terza/quarta run. Nelle
prime run infatti il governor powersave limita la frequenza di lavoro del processore
per risparimare energia.
La colonna IPC della tabella indica il valore medio dell'IPC a TD2 misurato sul
sistema. Il modello ha stimato che ad alto carico si raggiunga un IPC pari a 0,9631
mentre in realtà il valore massimo ottenuto è 0,7245 per la decima run. Il modello
quindi e�ettua una stima in eccesso rispetto al dato misurato realmente sul sistema
durante un workload ad alto carico. Questo accade perchè il modello stima l'IPC ad
alto carico (quindi a TD2) usando i dati raccolti a basso carico, ovvero quando vi è
una preponderanza di istruzioni ritirate durante cicli di clock trascorsi a
TD1 invece che a TD2. Con l'aumentare del carico aumentano i cicli di clock spesi
a TD2 e per questo la stima dell'IPC può risultare essere meno accurata. Se il sistema
avesse un carico leggermente superiore (pari al 50-60% di utilizzo tradizionale) e si
facesse la previsione considerando anche questi dati, si avrebbe un valore più preciso
della stima dell'IPC a TD2. Questo è sostenuto dal fatto che all'aumentare del carico
81
5.3. Esperimenti con RUBBoS
0 500 1000 1500
Throughput
1.0
1.2
1.4
1.6
1.8
2.0
Ave
rage
Thr
ead
Den
sity
Andamento dell’Average Thread DensityRUBBoS Benchmark
SUT: HT on, TB on, Governor powersave
ATD
Figura 5.5: RUBBoS TC1: andamento dell'ATD rispetto al Throughput, sistema incon�gurazione standard (governor powersave).
viene utilizzato sempre più il secondo thread hardware e pertanto la stima tiene conto
di un numero maggiore di istruzioni ritirate durante cicli di clock a TD2.
In questo esperimento abbiamo analizzato il comportamento usuale di un sistema
e abbiamo visto come si comporta la previsione e�ettuata tramite l'utilizzo tradizio-
nale e tramite la productivity. La prima porta con sè un grosso margine di errore,
cosa che la productivity riesce ad evitare. La productivity inoltre riesce a descrivere
e�ettivamente quanta capacità sia realmente utilizzata del processore, cosa che non
è percepibile dalla metrica di utilizzo.
5.3.2.2 TC3: Governor performance
Si mostrano ora i risultati degli esperimenti in cui è stato cambiato il gover-
nor a performance. Si vuole evidenziare come il governor non abbia comportato
cambiamenti nell'andamento delle performance del sistema utilizzando il benchmark
RUBBoS. Il governor performance quindi permette di avere una frequenza di lavoro
�ssa pari a quella massima disponibile dall'architettura.
Non si riportano i gra�ci in quanto il comportamento delle varie metriche risulta
essere il medesimo. I valori di accuratezza dei modelli basati sull'utilizzo tradizionale
e sulla productivity sono mostrati in Tabella 5.3. La regressione basata sul modello
della productivity ha dei risultati ancora una volta migliori rispetto alla regressione
basata sul modello dell'utilizzo tradizionale.
82
5.3. Esperimenti con RUBBoS
Tabella 5.2: RUBBoS TC1: risultati dell'esperimento sul sistema in con�gurazionestandard (governor powersave).
X U R (ms) P ATD AFREQ (GHz) IPC
174,4 10,3 1 7,78 1,18 2,016 0,5436349,9 14,15 1 14,34 1,21 2,685 0,5768524,4 20,12 1 21,31 1,26 2,826 0,606700 26,8 1 28,25 1,31 2,871 0,6253873,8 33,85 1 34,87 1,37 2,888 0,64011048,8 41,42 1 41,14 1,43 2,894 0,65171224,7 49,44 1 47,39 1,5 2,897 0,66561395,8 58,79 7,8 55,1 1,59 2,897 0,69471572,9 68,28 19,3 62,17 1,67 2,899 0,71911744,8 78,94 66,4 67,65 1,77 2,900 0,7245
Tabella 5.3: RUBBoS TC3: confronto tra gli R2 e i MAE dei modelli basati suUtilizzo Tradizionale e Productivity, sistema in con�gurazione standard (governorperformance).
Modello R2 MAE
Utilizzo Tradizionale 0,9264 3,8972Productivity 0,996 0,8859
Confrontando la Tabella 5.2 con i dati in Tabella 5.4 non vi sono notevoli di�e-
renze se non quella che l'AFREQ è pari al massimo consentito dal TB �n dalla prima
run dell'esperimento. Infatti il governor impostato a performance indica all'hardware
di utilizzare �n da subito tutta la frequenza a disposizione. Questo però non si ri-
percuote in un cambiamento delle performance a basso carico, se non che l'utilizzo
tradizionale è leggermente inferiore nella prima run, l'unica che bene�cia dell'au-
mento di frequenza. Sempre nella prima run si nota invece come la productivity sia
sostanzialmente invariata, segno che è una metrica indipendente dalla variazione di
frequenza, come vedremo nella Sezione 5.3.5. In�ne si nota sempre una certa dif-
ferenza tra l'IPC reale a carico alto (0,7232) e quello stimato dal modello a carico
basso (0,9614).
5.3.3 SUT con Turbo Boost non attivo
Si studia ora il comportamento del sistema nel caso in cui il Turbo Boost sia
disattivato, mentre il governor è settato a performance e l'Hyper-Threading è attivo
(TC4). Teoricamente il processore dovrebbe lavorare alla AFREQ massima pari
a 2.00 GHz (grazie al governor performance), ovvero la Processor Base Frequency
pubblicizzata da Intel per il processore del SUT.
83
5.3. Esperimenti con RUBBoS
Tabella 5.4: RUBBoS TC3: risultati dell'esperimento sul sistema in con�gurazionestandard (governor performance).
X U R (ms) P ATD AFREQ (GHz) IPC
174,2 7,18 1 7,85 1,15 2,843 0,5294349,5 13,18 1 14,52 1,2 2,877 0,572524,8 19,66 1 21,47 1,25 2,889 0,6038700,5 26,66 1 28,36 1,31 2,893 0,623875,3 33,97 1 35,08 1,37 2,896 0,63861048,9 41,41 1 41,06 1,43 2,896 0,64861224,1 49,39 1 47,32 1,5 2,898 0,66351398,1 58,38 2,9 54,24 1,58 2,897 0,68571570,6 68,32 29,3 61,67 1,68 2,899 0,71051741,6 79,65 99,3 68,01 1,79 2,898 0,7232
Tabella 5.5: RUBBoS TC4: confronto tra gli R2 e i MAE dei modelli basati suUtilizzo Tradizionale e Productivity, sistema con TB disattivo.
Modello R2 MAE
Utilizzo Tradizionale 0,8149 8,2506Productivity 0,9465 2,2986
Anche in questo caso si evidenzia una crescita non lineare dell'utilizzo tradiziona-
le, come mostra la Figura 5.6, dovuta principalmente all'utilizzo del secondo thread
hardware per mezzo dell'Hyper-Threading. In questo esperimento si nota come l'u-
tilizzo tradizionale raggiunga il 100%. Questo accade per il fatto che si è dovuto
ritarare RUBBoS su un livello più basso di carico, poichè il sistema con TB disat-
tivo non poteva elaborare una quantità di richieste pari a quella dell'esperimento a
sistema in con�gurazione standard. Il minor numero di client per nodo ha permesso
una gestione migliore della JVM e quindi non si sono presentate limitazioni durante
lo svolgimento dell'esperimento. In Figura 5.7 si riporta l'andamento della produc-
tivity rispetto al throughput. Essa ha un andamento lineare che viene previsto dalla
regressione in modo più accurato rispetto all'Utilization Law del modello tradizio-
nale, come mostrato dagli indici in Tabella 5.5. La metrica di productivity quindi
riesce a stimare la capacità del processore in modo più preciso rispetto all'utilizzo
tradizionale. In più, in concomitanza con i valori dell'utilizzo al 100%, si nota come
la productivity indichi che la capacità del processore venga utilizzata all'80% circa e
pertanto vi sia ancora spazio per elaborare istruzioni.
L'andamento dei tempi di riposta rispetto all'utilizzo tradizionale segue una cre-
scita pulita a mazza da hockey. Se guardiamo l'andamento rispetto alla productivity
(Figura 5.8) si nota come il tempo di risposta di alcune run sia salito notevolmente in
corrispondenza dell'utilizzo e della productivity al 100%. Queste run, visibili anche
84
5.3. Esperimenti con RUBBoS
0 200 400 600 800 1000 1200 1400
Throughput
0
20
40
60
80
100
Uti
lizzo
Tra
dizi
onal
eStima dell’Utilizzo Tradizionale (4 campioni)
RUBBoS BenchmarkSUT: HT on, TB off, Governor performance
Utilization LawUtilizzo Tradizionale
Figura 5.6: RUBBoS TC4: analisi di Utilizzo contro Throughput, sistema con TBdisattivo.
nelle immagini precedenti, sono casi particolari in cui il sistema ha avuto di�col-
tà nell'elaborazione del carico del benchmark. In ogni caso anche in questo gra�co
l'andamento è correttamente a mazza da hockey.
L'andamento dell'Average Thread Density del sistema è visibile in Figura 5.9.
L'ATD è sempre caratterizzato da una crescita graduale all'aumentare del workload.
In questo caso si nota che, grazie al carico ridotto rispetto all'esperimento precedente,
entrambi i thread vengono utilizzati dal sistema operativo quando il workload sul
sistema è al suo massimo. Si hanno infatti dei valori di ATD pari a due per le run
ad alto carico.
I risultati aggregati delle dieci run di questo esperimento sono riportati in Tabella
5.6. In particolare si evidenzia, come era stato supposto, che il sistema utilizza in
tutte le run l'AFREQ massima pari a 2.00GHz. L'IPC riportato indica il valore
medio a TD2 misurato sul sistema, in quanto l'HT è attivo. Il modello ha stimato
che ad alto carico si sarebbe raggiunto un IPC pari a 0,9034 mentre in realtà si ha
un valore pari a 0,7743 per la decima run.
Da questo esperimento abbiamo ottenuto una visione di come il sistema si com-
porti senza il Turbo Boost e si è evidenziato come l'analisi tradizionale tramite la
metrica di utilizzo continui a portare dei risultati errati, che possono invece essere
previsti correttamente dalla productivity.
85
5.3. Esperimenti con RUBBoS
0 200 400 600 800 1000 1200 1400
Throughput
0
20
40
60
80
100
Pro
duct
ivit
yStima della Productivity (4 campioni)
RUBBoS BenchmarkSUT: HT on, TB off, Governor performance
Regressione LineareProductivity
Figura 5.7: RUBBoS TC4: analisi di Productivity contro Throughput, sistema conTB disattivo.
5.3.4 SUT con Hyper-Threading non attivo
In questo esperimento si vuole studiare il comportamento del sistema nel caso in
cui l'Hyper-Threading sia disattivato, mentre il governor è settato a performance e
il TB è attivo (TC7). Il processore dovrebbe quindi lavorare all'AFREQ massima
consentita dal TB con i due core attivi, ovvero 2.90 GHz. Avendo disattivato l'HT ci
si potrebbe aspettare un modello quasi lineare nella crescita dell'utilizzo tradizionale,
benchè vi siano ancora dei fattori che introducono una non linearità meno accentuata,
come il Turbo Boost.
L'andamento dell'utilizzo tradizionale è mostrato in Figura 5.10: come previsto
la crescita è ancora non lineare, benchè la retta di previsione approssimi in modo
più accurato i dati reali, come mostrano i valori di R2 e MAE mostrati in Tabella
5.7. I valori del modello basato sull'utilizzo tradizionale indicano una previsione più
precisa rispetto agli esperimenti precedenti, mentre i valori del modello basato sulla
productivity indicano una precisione ancora più alta.
Anche in questo caso l'utilizzo tradizionale raggiunge il 100%, in quanto si è tarato
RUBBoS su un livello più basso di carico in modo che il sistema riuscisse ad eseguire
il benchmark senza l'HT. In Figura 5.11 è riportato l'andamento della productivity
rispetto al throughput. I valori di productivity ad alto carico si avvicinano al 100%,
valore che indica che le istruzioni ritirate dal processore hanno quasi raggiunto il
numero di istruzioni massime ritirabili stimate dal modello.
86
5.3. Esperimenti con RUBBoS
0 20 40 60 80 100
Productivity
0
500
1000
1500
2000
2500
3000
3500
Res
pons
eT
ime
(ms)
Andamento del Response Time rispetto alla ProductivityRUBBoS Benchmark
SUT: HT on, TB off, Governor performance
Response Time (ms)
Figura 5.8: RUBBoS TC4: andamento del Response Time rispetto alla Productivity,sistema con TB disattivo.
L'andamento dei tempi di risposta non viene riportato in gra�co, ma presenta
correttamente un andamento a mazza da hockey, come intuibile dai dati riportati
nella Tabella 5.8. In Figura 5.12 è visibile l'Average Thread Density del sistema.
Avendo disattivato l'Hyper-Threading è naturale che il sistema abbia utilizzato sem-
pre ed esclusivamente un solo thread harware, corrispondente al core �sico. L'ATD
quindi ha valore uno in tutte le run.
Dalla Tabella 5.8 si evidenzia come il sistema utilizzi in tutte le run l'AFREQ
massima permessa dal TB pari a 2,90GHz. L'utilizzo tradizionale raggiunge il 100%
già dall'ottava run, segno che RUBBoS è stato tarato in modo leggermente eccessivo
sulle ultime run. In questo caso l'IPC riportato indica il valore medio a TD1 poichè
l'HT non è attivo. Il modello ha stimato che ad alto carico si sarebbe raggiunto
un IPC pari a 0,5522 mentre in realtà si ha un valore pari a 0,5096 per la decima
run. L'IPC previsto a basso carico quindi ha un errore ridotto rispetto a quanto
e�ettivamente viene misurato ad alto carico. Questo è possibile in quanto a basso
carico si ha una Thread Density pari a uno, così come quando si è ad alto carico
grazie al fatto che l'Hyper-Threading non è attivo. Questo fa sì che la previsione
possa essere molto più accurata rispetto agli esperimenti ad HT attivo in cui viene
stimato l'IPC a TD2.
In questo esperimento abbiamo ottenuto una visione di come il sistema si compor-
ti quando l'Hyper-Threading non è attivo. Questa con�gurazione, benchè si avvalga
di tecnologie moderne, può iniziare a ricordare architetture più vecchie dal punto
87
5.3. Esperimenti con RUBBoS
Tabella 5.6: RUBBoS TC4: risultati dell'esperimento in cui il sistema ha il TBdisattivo.
X U R (ms) P ATD AFREQ (GHz) IPC
175,5 9,94 1 12,09 1,17 1,964 0,5605349,6 18,7 1 22,4 1,24 1,983 0,6069525,2 28,3 1 32,75 1,32 1,985 0,6401698,6 38,73 2 43,12 1,41 1,990 0,6688873,8 49,55 2,3 52,85 1,51 1,994 0,69371048,4 60,73 2 61,92 1,6 1,996 0,71551223 73,6 8,5 71,74 1,72 2,002 0,74311384,4 90,52 153,2 82,19 1,89 2,005 0,7711378,1 99,8 1072,6 84,77 2 2,009 0,76351252,6 99,51 2357,8 89,37 1,99 2,010 0,7743
Tabella 5.7: RUBBoS TC7: confronto tra gli R2 e i MAE dei modelli basati suUtilizzo Tradizionale e Productivity, sistema con HT disattivo.
Modello R2 MAE
Utilizzo Tradizionale 0,921 5,1707Productivity 0,9923 1,5631
Tabella 5.8: RUBBoS TC7: risultati dell'esperimento in cui il sistema ha l'HTdisattivo.
X U R (ms) P ATD AFREQ (GHz) IPC
174,4 13,92 1 13,14 1 2,790 0,488349,2 24,61 1 24,69 1 2,840 0,5301524,8 35,74 3,3 37,8 1 2,865 0,5633700,2 45,68 1 47,24 1 2,877 0,5566875,8 56,51 1 58,33 1 2,887 0,55961050,7 68,19 2 69,37 1 2,892 0,55541222,4 81,2 56,6 80,55 1 2,896 0,54611350,8 97,16 428,7 91,04 1 2,897 0,51911321,4 99,89 1427,2 91,42 1 2,894 0,50761304,1 99,89 2191,4 91,77 1 2,894 0,5096
88
5.3. Esperimenti con RUBBoS
0 200 400 600 800 1000 1200 1400
Throughput
1.0
1.2
1.4
1.6
1.8
2.0
Ave
rage
Thr
ead
Den
sity
Andamento dell’Average Thread DensityRUBBoS Benchmark
SUT: HT on, TB off, Governor performance
ATD
Figura 5.9: RUBBoS TC4: andamento dell'ATD rispetto al Throughput, sistemacon TB disattivo.
di vista della previsione con modelli lineari. La presenza del Turbo Boost e del go-
vernor, oltre ad altre innovazioni a livello di hardware, non permettono però una
linearità completa del modello di utilizzo tradizionale. L'aver disattivato l'HT per-
mette inoltre al modello basato sulla productivity di stimare con più precisione
l'IPC ad alto carico, in quanto in tale situazione viene utilizzato un solo thread
hardware sia ad alto che a basso carico.
5.3.5 Esperimenti a frequenze crescenti
Si vogliono ora e�ettuare degli esperimenti in cui le frequenze di lavoro ven-
gono pre�ssate a livelli ben de�niti. Si vuole capire quindi come si comportano i
modelli predittivi all'aumentare della frequenza di lavoro, comparando i vari esperi-
menti a frequenze crescenti. Ci si riferisce quindi al problema descritto nella Sezione
2.3.2. Benchè tale problema sia già stato a�rontato parzialmente con gli esperimenti
precedenti, si vuole valutare come reagisca la productivity in esperimenti in cui la
frequenza di lavoro viene pre�ssata a un determinato valore. Lavorando sui �le di
con�gurazione dell'Intel P-State Driver (si veda Sezione 1.1.6.2) è possibile cercare di
forzare la frequenza di funzionamento a un valore preciso, benchè si ricorda come esso
sia solo un'indicazione per l'hardware in quanto esso decide liberamente come com-
portarsi secondo la necessità. Si sono de�nite le seguenti frequenze di funzionamento
su cui e�ettuare un esperimento comparato:
89
5.3. Esperimenti con RUBBoS
0 200 400 600 800 1000 1200 1400
Throughput
0
20
40
60
80
100
Uti
lizzo
Tra
dizi
onal
eStima dell’Utilizzo Tradizionale (4 campioni)
RUBBoS BenchmarkSUT: HT off, TB on, Governor performance
Utilization LawUtilizzo Tradizionale
Figura 5.10: RUBBoS TC7: analisi di Utilizzo contro Throughput, sistema con HTdisattivo.
� 800 MHz: è la AFREQ più bassa raggiungibile dal processore del SUT.
Indichiamo questo esperimento con F0800.
� 1200 MHz: step intermedio di frequenza, a TB spento. Indichiamo questo
esperimento con F1200.
� 1600 MHz: step intermedio di frequenza, a TB spento. Indichiamo questo
esperimento con F1600.
� 2000 MHz: è la AFREQ pubblicizzata nella Processor Base Frequency, a TB
spento. Questa frequenza è già stata analizzata in un esperimento precedente
(si veda Sezione 5.3.3). Indichiamo questo esperimento con F2000.
� 2900 MHz: è la AFREQ massima raggiungibile con il TB. Questa frequenza
è già stata analizzata in un esperimento precedente (si veda Sezione 5.3.2).
Indichiamo questo esperimento con F2900.
A seconda dell'esperimento, il TB è stato acceso o spento e il governor settato a
powersave o performance. L'HT è invece sempre rimasto attivo. Per questo motivo
i test cases a�rontati sono molteplici.
Studiamo quindi l'andamento delle metriche al variare delle frequenze sopra de-
�nite. In Figura 5.13 è visibile il classico rapporto tra utilizzo tradizionale e th-
roughput. Si nota subito come entri in gioco la de�nizione di utilizzo tradizionale
90
5.3. Esperimenti con RUBBoS
0 200 400 600 800 1000 1200 1400
Throughput
0
20
40
60
80
100
Pro
duct
ivit
yStima della Productivity (4 campioni)
RUBBoS BenchmarkSUT: HT off, TB on, Governor performance
Regressione LineareProductivity
Figura 5.11: RUBBoS TC7: analisi di Productivity contro Throughput, sistema conHT disattivo.
dipendente dal numero di cicli di clock in cui il processore è rimasto attivo rispetto
alla frequenza di riferimento (TSC). Per tale motivo la curva di crescita dell'utiliz-
zo diventa man mano sempre meno pendente. Il processore può quindi elaborare
un diverso workload per uno stesso valore di utilizzo o, viceversa, elabora lo stesso
workload per diversi valori di utilizzo del processore. La variazione della frequenza
ha quindi un impatto molto forte nella determinazione dell'utilizzo tradizionale del
processore e questo fenomeno può portare problemi non indi�erenti nell'analisi di un
sistema. Si continuano ad evidenziare inoltre i comportamenti non lineari dei trend
di crescita dell'utilizzo, che si discostano dalle previsioni e�ettuate tramite l'Utiliza-
tion Law. Si riportano in Tabella 5.9 i valori di R2 e MAE per comparare le bontà
delle regressioni.
In Figura 5.14 è mostrato l'andamento della metrica di productivity e della sua
previsione per ogni esperimento a frequenza crescente. I valori della productivity
e le regressioni lineari sono coincidenti su un'unica retta: questo signi�ca che la
productivity è indipendente dalla variazione della frequenza di lavoro del processore.
Si riportano in Tabella 5.9 i valori di R2 e MAE, che evidenziano un'accuratezza
di stima molto maggiore. Questa nuova metrica quindi riesce a stimare la reale
capacità utilizzata del processore, come visibile dalla Tabella 5.10 dove vengono
messi a confronto i valori di utilizzo tradizionale e di productivity per le run a carico
massimo. Quando i valori di utilizzo raggiungono il 100%, la productivity indica
91
5.3. Esperimenti con RUBBoS
0 200 400 600 800 1000 1200 1400
Throughput
0.0
0.5
1.0
1.5
2.0
Ave
rage
Thr
ead
Den
sity
Andamento dell’Average Thread DensityRUBBoS Benchmark
SUT: HT off, TB on, Governor performance
ATD
Figura 5.12: RUBBoS TC7: andamento dell'ATD rispetto al Throughput, sistemacon HT disattivo.
invece la percentuale e�ettiva di capacità utilizzata del processore. Dalla medesima
tabella si possono vedere le AFREQ del processore durante le run ad alto carico:
queste frequenze corrispondono esattamente con quanto impostato sul sistema per
il rispettivo esperimento. In�ne dalla tabella si osserva come vi sia sempre una
di�erenza tra l'IPC reale misurato sul sistema e l'IPC stimato a basso carico, dovuto
al fatto che la stima viene fatta in un momento in cui il sistema sta lavorando a una
TD vicina ad uno.
In Figura si mostrano le ATD degli esperimenti al variare del throughput. Si
hanno sempre delle curve crescenti di ATD che indicano come per lo stesso throu-
ghput si possano avere ATD diverse poichè il processore sta lavorando a frequenze
diverse. Il processore infatti, al crescere della frequenza, inizia ad utilizzare il secon-
do thread sempre più tardi, in quanto il primo thread riesce a soddisfare le richieste
del workload autonomamente.
Si può quindi concludere che la metrica di productivity sia insensibile ai cambi
di frequenza, cosa che invece non accade per la metrica di utilizzo tradizionale. Il
fatto di riuscire a stimare la capacità del processore astraendosi dalla frequenza
di lavoro attuale è un vantaggio che permette di ottenere un valore di capacità
che non varia rispetto ai cambi di frequenza. Di conseguenza è possibile e�ettuare
stime che siano coerenti con la reale capacità del processore e che si comportino
proporzionalmente al throughput che viene elaborato dal sistema.
92
5.3. Esperimenti con RUBBoS
Tabella 5.9: RUBBoS Frequenze Crescenti: confronto tra gli R2 e i MAE dei mo-delli basati su Utilizzo Tradizionale e Productivity per gli esperimenti a frequenzecrescenti.
Modello Esperimento R2 MAE
Utilizzo Tradizionale
F0800 0,943 4,1025F1200 0,9605 3,6422F1600 0,9104 5,0308F2000 0,9173 4,8153F2900 0,9366 3,7301
Productivity
F0800 0,9947 0,3696F1200 0,9972 0,4046F1600 0,9976 0,3695F2000 0,9992 0,3227F2900 0,9916 1,126
Tabella 5.10: RUBBoS Frequenze Crescenti: Utilizzo tradizionale, Productivity,AFREQ, IPC misurato e IPC stimato per le run a carico massimo degli esperimentia frequenze crescenti.
Esperimento U P AFREQ (GHz) IPC misurato IPC stimato
F0800 98,78 24,47 0,828 0,8405 0,9808F1200 94,86 33,66 1,242 0,8077 1,008F1600 99,81 44,1 1,601 0,7877 0,9877F2000 90,48 53,4 2,001 0,7784 0,9662F2900 77,31 65,52 2,899 0,7251 0,9865
93
5.4. Esperimenti con CBench
0 500 1000 1500
Throughput
0
20
40
60
80
100
Uti
lizzo
Tra
dizi
onal
eStima dell’Utilizzo Tradizionale (4 campioni)
RUBBoS BenchmarkSUT: HT on, TB on, Governor performance
AFREQ 0,8 GHzAFREQ 1,2 GHzAFREQ 1,6 GHzAFREQ 2,0 GHzAFREQ 2,9 GHz
Figura 5.13: RUBBoS Frequenze Crescenti: analisi di Utilizzo contro Throughput,sistema in con�gurazione standard.
5.4 Esperimenti con CBench
In questa sezione si presentano i risultati ottenuti dagli esperimenti eseguiti con il
benchmark CBench del Politecnico di Milano, descritto nella Sezione 1.4.2. Verranno
mostrati gli esperimenti più interessanti che hanno permesso di ottenere, oltre alla
conferma dei risultati ottenuti con RUBBoS, anche la scoperta di fenomeni non
ancora analizzati. A di�erenza di RUBBoS, CBench risulta essere un benchmark
marcatamente CPU bounded (ad esempio, non e�ettua richieste a un database). I
risultati quindi sono stati ottenuti senza che vi fossero eccessivi colli di bottiglia
nell'utilizzo di risorse diverse dal processore del sistema (cache, memoria principale,
ecc...). L'unico problema incontrato è stato relativo al numero massimo di socket
aperte dal sistema operativo e dal numero di serventi del webserver. Dopo aver
aumentato tali valori nei �le di con�gurazione l'esecuzione degli esperimenti non ha
avuto inconvenienti.
94
5.4. Esperimenti con CBench
0 500 1000 1500
Throughput
0
20
40
60
80
100
Pro
duct
ivit
yStima della Productivity (4 campioni)
RUBBoS BenchmarkSUT: HT on, TB on, Governor performance
AFREQ 0,8 GHzAFREQ 1,2 GHzAFREQ 1,6 GHzAFREQ 2,0 GHzAFREQ 2,9 GHz
Figura 5.14: RUBBoS Frequenze Crescenti: analisi di Productivity controThroughput, sistema in con�gurazione standard.
5.4.1 Con�gurazione di una run
Il �le di con�gurazione di CBench presenta dei parametri che provengono dalla
teoria delle reti di code e che permettono in modo molto semplice di indicare i valori
caratteristici per l'esperimento che si vuole eseguire. Gli indirizzi del webserver e
delle altre risorse da contattare durante l'esecuzione del benchmark vengono indicati
in un apposito �le. Qui è indicato anche il Calibration Factor di ogni risorsa, ovvero
un valore numerico che deve essere calibrato prima del lancio del benchmark e che
permette di mantenere equivalenti i Service Demand anche tra server che hanno
caratteristiche hardware di�erenti.
Il workload di una run viene determinato dai seguenti parametri:
� N: numero totale di richieste che devono essere inviate durante il test. Se
moltiplicato per il tempo di interarrivo medio (l'inverso dell'Arrival Rate) si
ottiene la durata media complessiva del test. Tale parametro è stato scelto in
95
5.4. Esperimenti con CBench
0 500 1000 1500
Throughput
1.0
1.2
1.4
1.6
1.8
2.0
Ave
rage
Thr
ead
Den
sity
Andamento dell’Average Thread DensityRUBBoS Benchmark
SUT: HT on, TB on, Governor performance
AFREQ 0,8 GHzAFREQ 1,2 GHzAFREQ 1,6 GHzAFREQ 2,0 GHzAFREQ 2,9 GHz
Figura 5.15: RUBBoS Frequenze Crescenti: andamento dell'ATD rispetto alThroughput al variare delle frequenze di lavoro.
accordo con l'Arrival Rate in modo che si riuscisse ad e�ettuare una run di
lunghezza temporale almeno pari a cinque minuti.
� arrival: oggetto che contiene i dettagli sulla distribuzione probabilistica uti-
lizzata per generare gli arrivi delle richieste al server. Nei seguenti esperimenti
viene utilizzata una distribuzione esponenziale. Il rate della distribuzione è
il valore che viene cambiato lungo un test di CBench in quanto permette di
decidere la frequenza con cui le richieste vengono inviate al server durante la
speci�ca run. Controllando tale �usso è possibile somministrare al sistema un
workload più o meno consistente, permettendo di regolare quindi il carico che
il sistema deve elaborare. Le run a basso carico infatti hanno un tempo di
interarrivo maggiore, per cui si inviano al sistema meno richieste al secondo
e il carico sarà modesto. Nelle run successive si impostano via via dei tempi
di interarrivo più brevi, che risultano in un numero sempre maggiore di ri-
chieste inviate al server nell'unità di tempo, e di conseguenza un workload più
96
5.4. Esperimenti con CBench
consistente da elaborare.
� service: oggetto che contiene i dettagli sulla distribuzione probabilistica utiliz-
zata per generare i tempi di servizio di una richiesta presa in carico dal server.
Nei seguenti esperimenti viene utilizzata una distribuzione esponenziale. Il rate
della distribuzione è un valore che viene �ssato all'inizio di un test in quanto
esso determina il Service Time di una richiesta. Tale valore viene sempre con-
siderato costante in quanto si suppone che le richieste al server appartengano
a una classe di job che necessitano di un tempo elaborativo identico.
Complessivamente quindi una run di CBench dura cinque minuti. A causa del fatto
che nel benchmark non sono previste fasi di carico e scarico del workload e poichè
è stato evidenziato un comportamento molto stabile del benchmark durante tutto
l'intervallo, si è deciso di utilizzare i dati di tutto l'intervallo della run per calcolare
le metriche di performance.
5.4.2 SUT in con�gurazioni standard
Si replica l'esperimento in cui il SUT è con�gurato nel modo più standard possi-
bile, ovvero con Hyper-Threading attivo, Turbo Boost attivo e governor powersave
o performance. Questo ci permette di valutare l'impatto del governor sulle perfor-
mance del sistema nel caso di un workload come CBench. In questi esperimenti si è
impostato un Service Time di CBench pari a 1ms.
5.4.2.1 TC1: Governor powersave
Il comportamento del sistema con governor powersave risulta essere simile a quel-
lo visto nella Sezione 5.3.2.1, con la di�erenza che CBench permette di utilizzare in
modo molto più e�ciente il processore, essendo un benchmark CPU intensive. L'an-
damento dell'utilizzo tradizionale (Figura 5.16) presenta un'accentuata non linearità,
mentre l'andamento della productivity (Figura 5.17) è ancora una volta lineare. Le
regressioni hanno infatti valori di R2 e MAE molto di�erenti, confrontati nella Tabel-
la 5.11, che indicano come il modello basato sull'utilizzo tradizionale non permetta di
fare previsioni accurate. Considerando il throughput pari a 350 si vede come la pre-
visione tramite Utilization Law indichi un valore di utilizzo tradizionale leggermente
superiore al 60%, mentre i dati misurati sul sistema rivelano un utilizzo e�ettivo
dell'80%. Questa di�erenza risulta essere in generale molto importante quando si
vuole analizzare la QoS: le due percentuali di utilizzo corrispondono a tempi di ri-
sposta di�erenti e quindi sapere con precisione quale valore di utilizzo si raggiunge
con un determinato throughput è fondamentale per capire se il servizio subirà delle
degradazioni in termini di tempi di latenza. Nel caso della productivity invece questo
non accade, in quanto sia il valore stimato sia il valore e�ettivo in corrispondenza
del throughput pari a 350 è dell'80%.
97
5.4. Esperimenti con CBench
0 50 100 150 200 250 300 350 400
Throughput
0
20
40
60
80
100
Uti
lizzo
Tra
dizi
onal
eStima dell’Utilizzo Tradizionale (4 campioni)
CBench BenchmarkSUT: HT on, TB on, Governor powersave
Utilization LawUtilizzo TradizionaleAFREQ (GHz)
0.0
0.5
1.0
1.5
2.0
2.5
3.0
Act
ive
Fre
quen
cy(G
Hz)
×109
Figura 5.16: CBench TC1: analisi di Utilizzo e Active Frequency contro Throughput,sistema in con�gurazione standard (governor powersave).
Tabella 5.11: CBench TC1: confronto tra gli R2 e i MAE dei modelli basati suUtilizzo Tradizionale e Productivity, sistema in con�gurazione standard (governorpowersave).
Modello R2 MAE
Utilizzo Tradizionale 0,8263 7,7340Productivity 0,9997 0,1842
Nella Tabella 5.12 sono riportati i risultati aggregati delle dieci run di questo
esperimento. Il fatto che CBench riesca a sfruttare in modo intensivo il processore si
riscontra anche nel livello di utilizzo dei thread hardware. L'ATD infatti raggiunge
un valore vicino a due nel momento di carico massimo, indice del fatto che durante
l'intervallo vengono utilizzati quasi sempre entrambi i thread.
Il modello basato sulla productivity ha stimato che ad alto carico si raggiunga
un IPC pari a 1,5349 mentre in realtà si ha un valore di 1,373 per la decima run. Il
modello quindi e�ettua anche in questo caso una stima in eccesso dell'IPC, dovuto al
fatto che la stima è fatta su dati che vengono raccolti quando il sistema sta lavorando
a TD vicino a uno.
Durante l'esecuzione di questi esperimenti si è notato un comportamento molto
interessante da parte dell'andamento dei tempi di risposta. In particolare si eviden-
zia come nelle prime due run si abbiano dei tempi di risposta superiori a quelli attesi
e, anzi, paragonabili ai tempi di risposta ottenuti ad alto carico. Questo andamen-
to dei tempi di risposta viene chiamato a �vasca da bagno� ed è visibile in Figura
98
5.4. Esperimenti con CBench
0 50 100 150 200 250 300 350 400
Throughput
0
20
40
60
80
100
Pro
duct
ivit
yStima della Productivity (4 campioni)
CBench BenchmarkSUT: HT on, TB on, Governor powersave
Regressione LineareProductivity
Figura 5.17: CBench TC1: analisi di Productivity contro Throughput, sistema incon�gurazione standard (governor powersave).
5.18. L'andamento a �vasca da bagno� è dovuto al fatto che nelle run a basso cari-
co l'AFREQ del sistema non viene ancora spinta al suo massimo, mentre in questo
esperimento solo dalla quinta run l'AFREQ va a regime. Questo comportamento,
visibile in Figura 5.16, è dovuto al fatto che il governor powersave indica al sistema
di utilizzare una frequenza di lavoro bassa, visto che il workload è leggero e non vi è
necessità di performance elevate. In Figura 5.16 si vede come il governor powersave
faccia aumentare l'AFREQ col crescere del carico sul sistema. Come è stato già
evidenziato in [5], una frequenza di lavoro non elevata rende il Service Time
del sistema maggiore, con conseguente peggioramento del tempo di rispo-
sta dell'applicativo. Questo fenomeno è visibile soprattutto quando sul sistema
vi è un carico modesto in quanto le frequenze vengono tenute basse per limitare i
consumi. Benchè il sistema sia praticamente libero, dal lato dell'utente si ha invece
la percezione che sia molto occupato, in quanto i tempi di risposta dell'applicativo
sono elevati. Nella pratica industriale di analisi delle performance di un sistema
questo fenomeno è stato spesso identi�cato ma non se ne capivano le ragioni. Nel
caso degli esperimenti eseguiti con benchmark RUBBoS, comportamenti di questo
tipo non sono stati notati in quanto la frequenza a basso carico non è mai stata
signi�cativamente bassa da aumentare il Service Time del benchmark.
99
5.4. Esperimenti con CBench
Tabella 5.12: CBench TC1: risultati dell'esperimento sul sistema in con�gurazionestandard (governor powersave).
X U R (ms) P ATD AFREQ (GHz) IPC
19,3 10,32 2,75 4,91 1,13 1,031 1,052472,2 20,18 1,3 16,94 1,21 1,984 1,0887138,3 28,64 0,9 31,81 1,29 2,729 1,1292190,3 38,55 0,94 43,55 1,37 2,862 1,1789232,3 47,92 1,02 53,11 1,45 2,893 1,2201274,3 58,39 1,22 63,07 1,55 2,901 1,2693313,6 68,67 1,32 71,51 1,64 2,902 1,3064330,7 73,51 1,44 75,36 1,69 2,902 1,3257365,1 84,77 1,97 83,07 1,81 2,901 1,3634376,8 90,02 2,88 85,75 1,87 2,901 1,373
5.4.2.2 TC3: Governor performance
In questo esperimento si imposta il governor a performance, il quale indica al-
l'hardware di poter utilizzare tutta la frequenza a disposizione senza preoccuparsi
di tenerla bassa per risparmiare energia. Questa è quindi la con�gurazione in cui
il sistema può utilizzare al massimo le sue capacità, ottenendo le prestazioni più
performanti.
Il fatto che l'AFREQ sia massima �n dalle prime run fa sì che il Service
Time dell'applicazione non subisca alterazioni a basso carico e pertanto il
Response Time ha un valore che ci si aspetterebbe da un modello tradizionale a reti
di code. Come è visibile in Figura 5.19, l'andamento del Response Time è infatti
quello classico a �mazza da hockey�, in quanto si hanno valori crescenti a partire
dalla prima run che non generano un andamento a �vasca da bagno�.
Il comportamento dei tempi di risposta e della frequenza è visibile anche dai
dati aggregati in Tabella 5.13, che mostrano come l'AFREQ sia stata realmente
utilizzata al suo massimo �n da subito. Dalla tabella si evidenzia come l'Average
Thread Density abbia un costante aumento �no ad avere quasi valore due, indice
che a carico massimo i due thread hardware sono stati utilizzati al massimo. L'IPC
stimato a carico massimo dal sistema è pari a 1,6742 mentre in realtà si raggiunge
solo il valore di 1,3575 per la decima run.
Per quanto riguarda i modelli basati sull'utilizzo tradizionale e sulla productivity
non vi sono di�erenze nel loro andamento rispetto a quanto già visto. L'utilizzo
tradizionale ha sempre un comportamento non lineare, mentre la productivity ha
una crescita lineare. Gli indici di bontà delle rette di regressione sono visibili in
Tabella 5.14.
Si può quindi concludere a�ermando che il governor gioca un ruolo fon-
100
5.5. Esperimenti con SPECpower_ssj 2008
0 20 40 60 80 100
Utilizzo Tradizionale
0.0
0.5
1.0
1.5
2.0
2.5
3.0
3.5
Res
pons
eT
ime
(ms)
Andamento del Response Time rispetto all’Utilizzo TradizionaleCBench Benchmark
SUT: HT on, TB on, Governor powersave
Response Time (ms)
Figura 5.18: CBench TC1: andamento del Response Time rispetto all'Utilizzo,sistema in con�gurazione standard (governor powersave).
damentale nel determinare il Response Time dell'applicativo, soprattutto
quando il sistema è a basso carico in quanto non viene utilizzata la frequenza di lavo-
ro massima possibile. Questo fenomeno ha un e�etto sull'utilizzo dell'applicativo da
parte dell'utente, che ha un'esperienza d'uso simile a quando il sistema è oberato di
carico. Utilizzare una frequenza massima ovviamente evita questo e�etto, ma d'altra
parte aumentano sicuramente i consumi energetici del processore.
5.5 Esperimenti con SPECpower_ssj 2008
In questa sezione si presentano i risultati ottenuti dagli esperimenti eseguiti con il
benchmark SPECpower_ssj 2008 (abbreviato in SP) del consorzio SPEC, descritto
nella Sezione 1.4.3. SP è un benchmark industriale fatto in modo per essere uno
standard indipendente e pertanto non necessita di software di terze parti per la sua
esecuzione. Benchè l'installazione e la con�gurazione di SP siano processi articolati,
questo benchmark non ha presentato alcun tipo di problema durante la sua esecuzione
sul SUT. SP simula un sistema transazionale in cui degli utenti e�ettuano delle
richieste a un applicativo: questa sua natura però non ha in�uito sul tipo di workload
e�ettivo sul sistema, anzi il suo carico risulta essere decisamente CPU bounded, senza
so�rire di dipendenze da database o webserver.
Poichè SP è nato per rilevare il consumo energetico di un server, ai �ni di questa
tesi è stato utilizzato esclusivamente come generatore di carico per raccogliere e
101
5.5. Esperimenti con SPECpower_ssj 2008
0 20 40 60 80 100
Utilizzo Tradizionale
0
10
20
30
40
50
Res
pons
eT
ime
(ms)
Andamento del Response Time rispetto all’Utilizzo TradizionaleCBench Benchmark
SUT: HT on, TB on, Governor performance
Response Time (ms)
Figura 5.19: CBench TC3: andamento del Response Time rispetto all'Utilizzo,sistema in con�gurazione standard (governor performance).
analizzare i dati sulle performance. Infatti i demoni che controllano i rilevatori di
energia consumata e temperatura vengono eseguiti in modalità dummy, senza avere
e�etti sul corretto svolgimento dell'esperimento.
5.5.1 Con�gurazione di una run
SPECpower non necessita di essere con�gurato per stabilire il carico che deve
somministrare al sistema. Una volta lanciato, SP esegue una serie di run di cali-
brazione (generalmente tre) per determinare il carico massimo che il sistema può
elaborare. Successivamente SP esegue una scala discendente di dieci run, partendo
dal carico massimo e scendendo �no a quello minimo. In�ne SP esegue un'undicesima
run a carico nullo per veri�care il consumo del sistema quando è idle.
I �le di con�gurazione che bisogna modi�care solo in caso di necessità sono:
� SPECpower_ssj_con�g_sut.props: contiene informazioni relative alle
caratteristiche del SUT che vengono utilizzate nella reportistica del benchmark.
� SPECpower_ssj_EXPERT.props: contiene dei parametri per utenti
esperti come il numero di calibrazioni, le durate delle run e le con�gura-
zioni di rete (nomi degli host e porte). In particolare il parametro in-
put.load_level.number_warehouses dovrebbe essere settato pari al numero di
core logici del sistema. Cambiare alcuni di questi parametri può portare alla
102
5.5. Esperimenti con SPECpower_ssj 2008
Tabella 5.13: CBench TC3: risultati dell'esperimento sul sistema in con�gurazionestandard (governor performance).
X U R (ms) P ATD AFREQ (GHz) IPC
45,2 9,31 0,67 10,52 1,11 2,871 0,973667,5 13,05 0,7 14,76 1,15 2,893 1,0192147,8 28,55 0,83 31,36 1,28 2,912 1,1368203,8 40,55 0,94 43,04 1,38 2,910 1,2018240,9 49,4 1,04 50,97 1,46 2,908 1,2427274 57,52 1,14 57,67 1,54 2,906 1,2741307,2 67,39 2,06 64,85 1,63 2,904 1,3071334,3 75,22 2,05 70,45 1,71 2,903 1,3367368,2 88,55 4,96 77,82 1,87 2,901 1,3753376,7 96,91 25,75 79,73 1,96 2,900 1,3575
Tabella 5.14: CBench TC3: confronto tra gli R2 e i MAE dei modelli basati suUtilizzo Tradizionale e Productivity, sistema in con�gurazione standard (governorperformance).
Modello R2 MAE
Utilizzo Tradizionale 0,8854 6,2192Productivity 0,9989 0,5381
classi�cazione dell'esperimento come �Not compliant�, ovvero un esperimento
che non rispetta le linee guida standard richieste da SPEC.
Mantenendo la con�gurazione compliant una run dura cinque minuti e complessiva-
mente l'esecuzione di SP ha una durata di circa 75 minuti. Ogni run è strutturata
in tre fasi, in modo simile a RUBBoS: una fase di pre misurazione, una fase di mi-
surazione e una fase di post misurazione. Ai �ni della raccolta dei dati si è deciso di
considerare solo l'intervallo di misurazione, anche detto �session�, in quanto esso è
de�nito come l'intervallo in cui il benchmark ha un comportamento stabile.
5.5.2 SUT in con�gurazioni standard
Si eseguono anche con SPECpower gli esperimenti di base in cui il SUT è con�-
gurato in modo standard, ovvero con Hyper-Threading attivo, Turbo Boost attivo e
governor powersave o performane. Questo ci permette di valutare anche con questo
benchmark l'andamento delle metriche di interesse.
5.5.2.1 TC1: Governor powersave
Con il governor powersave il comportamento del sistema risulta essere simile a
quanto già visto per RUBBoS e CBench. Essendo SP un benchmark professionale,
103
5.5. Esperimenti con SPECpower_ssj 2008
Tabella 5.15: SPECpower TC1: confronto tra gli R2 e i MAE dei modelli basati suUtilizzo Tradizionale e Productivity, sistema in con�gurazione standard (governorpowersave).
Modello R2 MAE
Utilizzo Tradizionale 0,8022 6,388Productivity 0,9985 0,8828
esso riesce a calibrarsi in modo da portare al massimo l'utilizzo tradizionale del
sistema, come mostrato dai valori dell'utilizzo in Figura 5.20. Contestualmente viene
mostrato l'andamento della frequenza media attiva di funzionamento (AFREQ). La
previsione fatta con l'Utilization Law risulta comunque essere errata all'aumentare
del throughput, con una non linearità decisamente accentuata. Gli indici di bontà
delle regressioni sono mostrati in Tabella 5.15.
0 20000 40000 60000 80000 100000 120000 140000 160000
Throughput
0
20
40
60
80
100
Uti
lizzo
Tra
dizi
onal
e
Stima dell’Utilizzo Tradizionale (4 campioni)SPECpower ssj 2008 Benchmark
SUT: HT on, TB on, Governor powersave
Utilization LawUtilizzo TradizionaleAFREQ (GHz)
0.0
0.5
1.0
1.5
2.0
2.5
3.0
Act
ive
Fre
quen
cy(G
Hz)
×109
Figura 5.20: SPECpower TC1: analisi di Utilizzo e Active Frequency controThroughput, sistema in con�gurazione standard (governor powersave).
L'andamento della productivity (Figura 5.21) è ancora una volta lineare, ma
in questo esperimento si nota una particolarità: la productivity va oltre il 100%.
Questo signi�ca che, rispetto alla previsione fatta a basso carico relativa alle istruzioni
massime ritirabili, il sistema in realtà ha ritirato più istruzioni quando si è trovato ad
alto carico. Pertanto il rapporto ha dato un valore superiore al 100%. Infatti, come
si mostra nella Tabella 5.16, l'IPC reale ad alto carico è pari a 1,5665 mentre l'IPC
stimato dal modello è 1,4471. In questo caso il modello e�ettua una stima per difetto,
rendendo ancora più evidente come il modello sia dipendente dal comportamento del
workload. Se dal sistema si potessero raccogliere dati relativi a un workload maggiore,
104
5.5. Esperimenti con SPECpower_ssj 2008
0 20000 40000 60000 80000 100000 120000 140000 160000
Throughput
0
20
40
60
80
100
Pro
duct
ivit
yStima della Productivity (4 campioni)
SPECpower ssj 2008 BenchmarkSUT: HT on, TB on, Governor powersave
Regressione LineareProductivity
Figura 5.21: SPECpower TC1: analisi di Productivity contro Throughput, sistemain con�gurazione standard (governor powersave).
il modello riuscirebbe ad e�ettuare una stima più precisa.
Si evidenzia come SPECpower riesca a sfruttare il processore in modo ancora
più intensivo rispetto a CBench. L'ATD infatti raggiunge il valore 1,95 a massimo
carico, valore che s�ora il massimo parallelismo dei thread hardware (Figura 5.22).
Anche in questo esperimento si veri�ca il comportamento a �vasca da bagno� dei
tempi di risposta, visibile dai dati riportati in Tabella 5.16. Esso è dovuto al fatto che
la frequenza a basso carico non viene spinta al massimo in quanto è attivo il governor
powersave, che fa crescere l'AFREQ contestualmente al carico a cui il sistema è
sottoposto. In Figura 5.20 è visibile l'andamento crescente dell'AFREQ, che parte
da un valore di 1,2 GHz �no a raggiungere 2,9 GHz, valore massimo consentito dal
Turbo Boost del SUT. La di�erenza dei tempi di risposta non è accentuata come per
il test e�ettuato con CBench, eppure il fenomeno si veri�ca anche con SP.
5.5.2.2 TC3: Governor performance
Si mostrano ora i risultati degli esperimenti in cui è stato cambiato il governor a
performance, che permette di avere �n dalla prima run una frequenza di lavoro �ssa
pari a quella massima disponibile dall'architettura.
L'andamento dell'utilizzo tradizionale, riportato in Figura 5.23, è ancora più
marcato rispetto ai casi precedenti. La non linearità mostra un evidente distacco
dalla retta di previsione dell'Utilization Law, come confermato dagli indici di a�-
105
5.5. Esperimenti con SPECpower_ssj 2008
0 20000 40000 60000 80000 100000 120000 140000 160000
Throughput
1.0
1.2
1.4
1.6
1.8
2.0
Ave
rage
Thr
ead
Den
sity
Andamento dell’Average Thread DensitySPECpower ssj 2008 Benchmark
SUT: HT on, TB on, Governor powersave
ATD
Figura 5.22: SPECpower TC1: andamento dell'ATD rispetto al Throughput, sistemain con�gurazione standard (governor powersave).
dabilità della regressione riportati in Tabella 5.17. Non si riporta l'andamento della
productivity, ma dai dati mostrati in Tabella 5.17 e in Tabella 5.18 si evince come
l'andamento sia perfettamente lineare. La stima e�ettuata con la metrica di utilizzo
tradizionale è portatrice di errore anche nel caso in cui il governor del sistema sia
impostato a performance.
Visionando la Tabella 5.18 si nota come l'AFREQ abbia il valore massimo con-
sentito dal Turbo Boost già dalla prima run dell'esperimento, grazie al fatto che è
attivo il governor performance. In questo caso si sottolinea come i tempi di rispo-
sta abbiano un andamento crescente a mazza da hockey, senza presentare l'e�etto
a �vasca da bagno�. In�ne in questo esperimento si ha un valore di IPC reale ad
alto carico pari a 1,5923 mentre il valore di IPC stimato dal modello di productivi-
ty è 1,816, segno che anche con il governor performance si ha una sovrastima delle
istruzioni ritirabili per ciclo.
5.5.3 Esperimenti con HT e TB non attivi
I due esperimenti seguenti vogliono indagare come si comportano le metriche
in un sistema che non ha attivi nè l'Hyper-Threading nè il Turbo Boost. L'unica
di�erenza sarà l'utilizzo del governor powersave o del governor performance, che
varia il modo in cui il processore gestisce la frequenza di lavoro. In questo modo
si potranno fare delle considerazioni su come la metrica di utilizzo tradizionale e la
106
5.5. Esperimenti con SPECpower_ssj 2008
Tabella 5.16: SPECpower TC1: risultati dell'esperimento sul sistema incon�gurazione standard (governor powersave).
X U R (ms) P ATD AFREQ (GHz) IPC
15170,7 13,98 35,8 11,07 1,13 1,257 1,47330156,8 21,06 29,9 21,72 1,19 1,725 1,48445547,4 26,53 26,6 32,67 1,24 2,152 1,476360233,8 31,87 25,3 42,92 1,28 2,441 1,475175763,1 38,46 26,1 54 1,33 2,655 1,478290840,2 45,61 28,1 64,51 1,39 2,782 1,4836105648,5 54,6 33,5 75,23 1,47 2,859 1,4869120515,4 65,44 46,4 85,77 1,58 2,894 1,4973136320 79,33 77,5 97,12 1,72 2,905 1,5212150465,3 96,73 1193,6 107,26 1,95 2,900 1,5665
Tabella 5.17: SPECpower TC3: confronto tra gli R2 e i MAE dei modelli basati suUtilizzo Tradizionale e Productivity, sistema in con�gurazione standard (governorperformance).
Modello R2 MAE
Utilizzo Tradizionale 0,7835 8,1127Productivity 0,9967 1,1524
Tabella 5.18: SPECpower TC3: risultati dell'esperimento sul sistema incon�gurazione standard (governor performance).
X U R (ms) P ATD AFREQ (GHz) IPC
14875,8 5,93 14,8 8,86 1,07 2,934 1,362529931,2 11,94 16,1 17,59 1,11 2,980 1,414944764 18,46 17,4 26,19 1,16 2,986 1,437759720,7 25,46 19,2 34,74 1,22 2,982 1,456374646,7 33,61 22,3 43,52 1,28 2,969 1,469189629,2 42,16 25,6 52,07 1,36 2,958 1,4878104606,4 52,52 31,7 60,82 1,45 2,943 1,4981119625,4 64,48 43,5 69,56 1,56 2,928 1,5153135077 78,81 75,7 78,59 1,71 2,913 1,5451149065,6 96,52 828 86,83 1,95 2,901 1,5923
107
5.5. Esperimenti con SPECpower_ssj 2008
0 20000 40000 60000 80000 100000 120000 140000 160000
Throughput
0
20
40
60
80
100
Uti
lizzo
Tra
dizi
onal
eStima dell’Utilizzo Tradizionale (4 campioni)
SPECpower ssj 2008 BenchmarkSUT: HT on, TB on, Governor performance
Utilization LawUtilizzo Tradizionale
Figura 5.23: SPECpower TC3: analisi di Utilizzo contro Throughput, sistema incon�gurazione standard (governor performance).
productivity considerino la variabilità della frequenza, ovvero il problema descritto
nella Sezione 2.3.2.
5.5.3.1 TC6: Governor powersave
In questa con�gurazione il SUT viene privato di tutte le componenti che ne
aumentano le performance. In particolare il governor è settato a powersave e pertanto
il sistema tenderà ad utilizzare la frequenza minore possibile per gestire il carico
di lavoro. Si riportano in Tabella 5.19 i risultati aggregati dell'esperimento. In
particolare si evidenzia che:
� l'ATD ha sempre valore pari a uno in quanto l'HT è spento;
� l'AFREQ cresce �no a raggiungere il valore di 2 GHz, frequenza massima senza
il TB;
� i tempi di risposta hanno una leggera �essione partendo dalla prima run,
ma non si ha una �vasca da bagno� così spiccata come visto in esperimenti
precedenti;
� l'IPC stimato (in questo caso a TD1) è pari a 1,4939 ed è esattamente in linea
con l'IPC misurato ad alto carico (1,4952);
108
5.5. Esperimenti con SPECpower_ssj 2008
Tabella 5.19: SPECpower TC6: risultati dell'esperimento sul sistema con HT o�,TB o� e governor powersave.
X U R (ms) P ATD AFREQ (GHz) IPC
10097,3 19,16 37,8 10,54 1 1,105 1,4419963,2 31,55 36,3 20,38 1 1,284 1,485229965,1 41,27 35,4 30,37 1 1,465 1,493540238 49,68 35,3 40,53 1 1,619 1,500450310,9 57,35 36,3 50,49 1 1,750 1,500860049 64,74 39,6 60,16 1 1,853 1,498370383,2 73,45 47 70,95 1 1,930 1,495880653 82,18 63,3 81,09 1 1,977 1,49390141,8 90,62 114,1 90,46 1 1,998 1,495199234,3 99,34 2057,4 99,39 1 2,004 1,4952
Tabella 5.20: SPECpower TC6: confronto tra gli R2 e i MAE dei modelli basati suUtilizzo Tradizionale e Productivity, sistema con HT o�, TB o� e governor powersave.
Modello R2 MAE
Utilizzo Tradizionale 0,9301 5,1701Productivity 0,9984 0,7914
� la productivity raggiunge il 100% a carico massimo, segno che la stima dell'I-
PC è stata realmente confermata e pertanto la capacità del processore viene
calcolata perfettamente (Figura 5.24).
Da questi dati però non si può apprezzare l'andamento dell'utilizzo tradizionale,
che viene quindi mostrato in Figura 5.25. In questo caso si può notare come a basso
carico vi sia un comportamento anomalo dell'utilizzo tradizionale, sopravvalutato
rispetto all'andamento usuale. Questo porta ad avere una previsione ad alto carico
mediante l'Utilization law che sovrastima il reale utilizzo del sistema. Il comporta-
mento a basso carico è proprio dovuto al fatto che il governor powersave fa utilizzare
al processore una frequenza bassa e pertanto l'utilizzo tradizionale viene calcolato
in modo concorde con i cicli spesi a quella frequenza (come mostrato nella Sezione
5.3.5). La metrica di utilizzo è quindi soggetta alle variazioni di frequenza, cosa che
risulta in una stima errata del vero utilizzo del processore. La productivity invece
riesce a tenere in considerazione le variazioni di frequenza utilizzando in modo ap-
propriato i cicli di clock che vengono spesi a frequenze di�erenti. In Tabella 5.20 si
confrontano gli indici R2 e MAE delle due regressioni.
In particolare si vuole evidenziare come il Service Demand a basso carico venga
in�uito dalla frequenza. Esso viene ottenuto come rapporto tra utilizzo tradizionale
e throughput (formula inversa dell'Utilization Law) e si ottengono i dati mostrati
in Tabella 5.21. Il Service Demand diminuisce costantemente con il procedere delle
109
5.5. Esperimenti con SPECpower_ssj 2008
0 20000 40000 60000 80000 100000 120000
Throughput
0
20
40
60
80
100
Pro
duct
ivit
yStima della Productivity (4 campioni)
SPECpower ssj 2008 BenchmarkSUT: HT off, TB off, Governor powersave
Regressione LineareProductivity
Figura 5.24: SPECpower TC6: analisi di Productivity contro Throughput, sistemacon HT o�, TB o� e governor powersave.
run, raggiungendo a carico massimo un valore pari alla metà rispetto a quello di
partenza. L'AFREQ si comporta esattamente all'inverso, partendo da un valore pa-
ri alla metà dell'AFREQ massimo raggiunto nell'ultima run (la frequenza massima
senza TB pari a 2 GHz). Questo comportamento è dovuto al fatto che sul sistema
è impostato il governor powersave, il quale tende a tenere la frequenza di lavoro il
più basso possibile. Se da un lato si risparmia in energia consumata, dall'altro però
i Service Demand elevati risultano in un elevato Response Time del sistema, pena-
lizzando l'utilizzo dell'applicativo da parte degli utenti. Quindi, paradossalmente, se
sul sistema ci sono pochi utenti questo cercherà di risparmiare energia tenendo una
frequenza bassa e l'esperienza degli utenti sarà peggiore (tempi di attesa alti, reat-
tività del sistema bassa, ecc...) rispetto a quando sul sistema c'è un carico elevato
di richieste. Il fatto che questo evento accada dipende esclusivamente da come il
sistema è con�gurato. Anche in questa circostanza eseguire la stima della capacità
del sistema tramite l'utilizzo tradizionale porta un errore non trascurabile, cosa che
viene evitata dalla productivity.
5.5.3.2 TC8: Governor performance
In questa con�gurazione il sistema non ha a disposizione nè l'HT nè il TB, oltre al
fatto che con il governor performance la frequenza di lavoro è �ssa, pari a quella mas-
sima consentita (2 GHz per il SUT considerato). Questo test case serve per mostrare
come si comporta un processore moderno privato di alcune delle tecnologie principali
110
5.5. Esperimenti con SPECpower_ssj 2008
0 20000 40000 60000 80000 100000 120000
Throughput
0
20
40
60
80
100
Uti
lizzo
Tra
dizi
onal
eStima dell’Utilizzo Tradizionale (4 campioni)
SPECpower ssj 2008 BenchmarkSUT: HT off, TB off, Governor powersave
Utilization LawUtilizzo Tradizionale
Figura 5.25: SPECpower TC6: analisi di Utilizzo contro Throughput, sistema conHT o�, TB o� e governor powersave.
che lo di�erenziano da un processore tradizionale. Si suppone che l'andamento delle
metriche di performance di questo sistema sia decisamente simile a quello previsto
dalle leggi tradizionali. Nello speci�co ci si so�ermerà sugli e�etti che la frequenza
�ssa permette di ottenere in termini di comportamento dell'utilizzo tradizionale e
dei tempi di risposta.
I dati aggregati dell'esperimento sono mostrati in Tabella 5.22. In particolare si
evidenzia che:
� l'AFREQ ha un valore costante pari a 2 GHz per tutte le run;
� i tempi di risposta hanno un andamento crescente �n dalla prima run, come si
vede dal comportamento tradizionale a mazza da hockey in Figura 5.26. Grazie
al fatto che la frequenza ha sempre avuto il valore massimo possibile non vi
sono stati e�etti di Service Demand alterato a basso carico;
� l'IPC stimato a TD1 è pari a 1,4709 ed è leggermente inferiore all'IPC misurato
ad alto carico (1,5006), rimanendo comunque una stima molto precisa;
� come conseguenza della leggera sottostima dell'IPC, la productivity supera
appena il 100% a carico massimo.
In questo caso l'andamento dell'utilizzo tradizionale ha un comportamento lineare
che viene previsto correttamente dall'Utilization Law, come mostrato in Figura 5.27.
Tale comportamento conferma come le recenti tecnologie quali l'Hyper-Threading
111
5.5. Esperimenti con SPECpower_ssj 2008
Tabella 5.21: SPECpower TC6: andamento dei Service Demand al crescere dellaAFREQ, sistema con HT o�, TB o� e governor powersave.
Service Demand Di�erenza % AFREQ %
0,001897537 100 55,160,001580408 83,28 64,090,0013772689 72,58 73,110,0012346538 65,06 80,80,001139912 60,07 87,330,0010781195 56,81 92,460,0010435729 54,99 96,330,001018933 53,69 98,640,001005305 52,97 99,740,0010010652 52,75 100
Tabella 5.22: SPECpower TC8: risultati dell'esperimento sul sistema con HT o�,TB o� e governor performance.
X U R (ms) P ATD AFREQ (GHz) IPC
9841,6 10,98 20,5 10,56 1 1,973 1,364919976,3 21,5 22 21,45 1 1,988 1,445230003,7 30,69 23,9 31 1 1,996 1,471440087,3 40,53 26 41,16 1 1,997 1,486149892 50,06 29 51,03 1 1,999 1,494660037 60,09 34 61,26 1 1,999 1,498669877,8 70,54 43,1 71,86 1 1,999 1,49979869,6 80,24 60,5 81,78 1 2,000 1,500789716,1 89,96 113,6 91,69 1 2,000 1,501999065 99,32 1937,5 101,11 1 2,000 1,5006
112
5.5. Esperimenti con SPECpower_ssj 2008
0 20 40 60 80 100
Utilizzo Tradizionale
0
500
1000
1500
2000
2500
3000
3500
Res
pons
eT
ime
(ms)
Andamento del Response Time rispetto all’Utilizzo TradizionaleSPECpower ssj 2008 Benchmark
SUT: HT off, TB off, Governor performance
Response Time (ms)
Figura 5.26: SPECpower TC8: andamento del Response Time rispetto all'Utilizzo,sistema con HT o�, TB o� e governor performance.
Tabella 5.23: SPECpower TC8: confronto tra gli R2 e i MAE dei modelli basa-ti su Utilizzo Tradizionale e Productivity, sistema con HT o�, TB o� e governorperformance.
Modello R2 MAE
Utilizzo Tradizionale 0,9979 0,8585Productivity 0,9986 0,6001
e il Dynamic frequency scaling abbiano un impatto notevole sulle performance (e i
relativi modelli di previsione) dei moderni processori. Come si è visto, disabilitando
tali tecnologie si ottiene un comportamento uguale a quello che si otteneva con i
processori tradizionali, come era stato descritto in Sezione 1.2.2.
In questa con�gurazione il modello tradizionale riesce ad eseguire una pre-
visione corretta, come è naturale aspettarsi in quanto la con�gurazione si avvicina
ai sistemi tradizionali su cui è stata sviluppata ed applicata l'Utilization Law. Tale
previsione è confermata dagli indici R2 e MAE mostrati in Tabella 5.23, dove si vede
che il valore di R2 è quasi pari a uno per il modello tradizionale. Il modello basato
sulla productivity si comporta linearmente come sempre (Figura 5.28) e riesce an-
che in questo caso ad avere dei valori degli indici di bontà della regresione migliori
rispetto all'utilizzo tradizionale.
113
5.5. Esperimenti con SPECpower_ssj 2008
0 20000 40000 60000 80000 100000 120000
Throughput
0
20
40
60
80
100
Uti
lizzo
Tra
dizi
onal
eStima dell’Utilizzo Tradizionale (4 campioni)
SPECpower ssj 2008 BenchmarkSUT: HT off, TB off, Governor performance
Utilization LawUtilizzo Tradizionale
Figura 5.27: SPECpower TC8: analisi di Utilizzo contro Throughput, sistema conHT o�, TB o� e governor performance.
0 20000 40000 60000 80000 100000 120000
Throughput
0
20
40
60
80
100
Pro
duct
ivit
y
Stima della Productivity (4 campioni)SPECpower ssj 2008 Benchmark
SUT: HT off, TB off, Governor performance
Regressione LineareProductivity
Figura 5.28: SPECpower TC8: analisi di Productivity contro Throughput, sistemacon HT o�, TB o� e governor performance.
114
Capitolo 6
Sintesi dei risultati
Gli esperimenti mostrati in precedenza hanno permesso di a�rontare le due pro-
blematiche sollevate nella Sezione 2.3, relative all'analisi e alla stima delle prestazioni
dei moderni processori che si avvalgono del Simultaneous multithreading (nel no-
stro caso si è utilizzata l'implementazione Hyper-Threading di Intel) e del Dynamic
frequency scaling (EIST e Turbo Boost per Intel). Gli e�etti di non linearità del
modello basato sull'utilizzo tradizionale scompaiono con l'introduzione del modello
basato sulla productivity, che permette quindi di e�ettuare una stima più robusta
della capacità di un processore. Dai risultati degli esperimenti si possono evidenziare
i seguenti punti salienti relativi all'applicazione della metrica di productivity:
� tramite il modello basato sulla metrica di productivity è possibile stimare la ca-
pacità utilizzata del processore in modo accurato, in quanto la retta di previsio-
ne ha indici di precisione migliori rispetto a quelli ottenuti dall'applicazione del-
l'Utilization Law. Visto da una prospettiva diversa, il modello di producti-
vity riesce a stimare con precisione maggiore il valore del throughput
atteso dal sistema ad alto carico. Infatti la stima fatta tramite l'Utilization
Law risulta in un throughput che non corrisponde al reale valore di utilizzo tra-
dizionale del sistema. Nelle Figure 6.1, 6.2, 6.3 e 6.4 si vedono le percentuali di
accuratezza della previsione del throughput per gli esperimenti descritti in pre-
cedenza. La percentuale di accuratezza nella stima del throughput è calcolata
come proporzione del throughput stimato rispetto a quello misurato a carico
alto: Stima throughput (%) =Xmax_stimato∗100Xmax_misurato . Il valore di Xmax_stimato
viene calcolato utilizzando il coe�ciente angolare e l'intercetta della retta di
regressione del modello di interesse (basato sull'utilizzo tradizionale o sulla pro-
ductivity) considerando l'utilizzo tradizionale (o la productivity) misurato ad
alto carico in corrispondenza dell'Xmax_misurato. Si riporta la formula nel
caso dell'utilizzo tradizionale: Xmax_stimato =Umax_misurato−intercetta
coe�ciente_angolare . Lo
stesso viene fatto per calcolare l'accuratezza del throughput stimato tramite
productivity. Un'accuratezza del 100% indica che il throughput stimato corri-
115
sponde al throughput e�ettivo misurato a carico massimo. Come si vede dalle
�gure, il modello basato sulla productivity risulta avere una percentuale di ac-
curatezza sempre migliore rispetto al modello tradizionale, con valori più vicini
al 100%. Il modello tradizionale ha tendenzialmente percentuali maggiori del
100%, segno che esso sovrastima il throughput massimo in quanto la retta di
previsione stima usualmente per difetto l'utilizzo e�ettivo;
� la productivity riesce ad evitare gli e�etti di non linearità dell'utilizzo tradizio-
nale, dovuti principalmente all'introduzione dell'Hyper-Threading sui proces-
sori Intel. Anche quando l'HT risulta non utilizzato, la stima ottenuta dalla
productivity continua ad avere un comportamento lineare;
� a di�erenza dell'utilizzo tradizionale, la productivity risulta essere indipendente
dalle tecnologie che variano la frequenza del processore, quali il Turbo Boost
di Intel e gli Intel P-States gestiti dal governor del sistema;
� il modello proposto risulta essere applicabile concettualmente a tutte le ar-
chitetture che supportano la raccolta degli indici di prestazioni di interesse (i
Performance Counters o loro equivalenti);
� il modello stima l'IPC a carico alto utilizzando campioni raccolti quando il
sistema è a basso carico, ovvero quando il processore consuma la maggior parte
dei cicli lavorando ad una Thread Density vicina a uno. Questa è la motivazione
alla base della di�erenza di valore tra l'IPC reale e quello stimato per una
Thread Density idealmente pari a due. Tale errore si riduce nel caso in cui si
consideri un numero maggiore di campioni, con il sistema via via più carico di
lavoro. Nel caso in cui l'HT sia disattivato, la stima fatta con Thread Density
pari a uno risulta essere sempre accurata, in quanto il valore reale di IPC
misurato sul sistema conferma il valore stimato dal modello;
� si è confermato il fatto che se il sistema sta eseguendo un basso carico di lavoro
a una frequenza che non è la massima consentita, allora si veri�ca un aumento
del Service Time, che si ri�ette in Response Time dell'applicativo maggiori.
L'andamento del Response Time rispetto al throughput assume quindi una
forma a �vasca da bagno�. Questo fenomeno scompare se si impone una fre-
quenza di lavoro �ssa (nei nostri esperimenti la massima frequenza possibile,
tramite governor performance), in quanto i Service Time a basso carico non
hanno un incremento. L'andamento del Response Time torna ad essere quello
classico a �mazza da hockey�.
116
HT on, TB on,Gov powersave
HT on, TB on,Gov performance
HT on, TB off,Gov performance
HT off, TB on,Gov performance
0
20
40
60
80
100
120
140
160
Accuratezza dei modelli nella stima del ThroughputRUBBoS Benchmark
Modello Utilizzo Tradizionale Modello Productivity
Stim
a T
hrou
ghpu
t (%
)
Figura 6.1: Percentuali di stima del throughput degli esperimenti eseguiti conbenchmark RUBBoS.
0,8 Ghz 1,2 Ghz 1,6 Ghz 2,0 Ghz 2,9 Ghz0
20
40
60
80
100
120
140
Accuratezza dei modelli nella stima del Throughputal variare della frequenza (AFREQ)
RUBBoS BenchmarkSUT: HT on, TB on, Governor performance
Modello Utilizzo Tradizionale Modello Productivity
Stim
a T
hrou
ghpu
t (%
)
Figura 6.2: Percentuali di stima del throughput degli esperimenti a frequenzecrescenti eseguiti con benchmark RUBBoS.
117
HT on, TB on, Gov powersave HT on, TB on, Gov performance0
20
40
60
80
100
120
140
160
Accuratezza dei modelli nella stima del ThroughputCBench Benchmark
Modello Utilizzo Tradizionale Modello Productivity
Stim
a T
hrou
ghpu
t (%
)
Figura 6.3: Percentuali di stima del throughput degli esperimenti eseguiti conbenchmark CBench.
HT on, TB on,Gov powersave
HT on, TB on,Gov performance
HT off, TB off,Gov powersave
HT off, TB off,Gov performance
0
20
40
60
80
100
120
140
160
Accuratezza dei modelli nella stima del ThroughputSPECpower_ssj 2008 Benchmark
Modello Utilizzo Tradizionale Modello Productivity
Stim
a T
hrou
ghpu
t (%
)
Figura 6.4: Percentuali di stima del throughput degli esperimenti eseguiti conbenchmark SPECpower.
118
Conclusioni
In questa tesi è stato proposto un modello innovativo per analizzare e stimare la
reale capacità elaborativa di un processore moderno. Tale studio, rientrante nel cam-
po delle performance dei sistemi informatici, ha portato alla de�nizione della metrica
chiamata productivity. Essa è stata ideata per sopperire ai limiti del modello basato
sulla metrica di utilizzo tradizionale, che sono comparsi con l'introduzione delle più
recenti tecnologie hardware e software. In particolare tale metrica vuole essere uti-
lizzata sui processori Intel, carenti attualmente di una soluzione a questo problema,
benchè possa essere applicata concettualmente a qualsiasi tipo di processore.
La necessità di avere una metrica a�dabile è infatti di vitale importanza sia per
monitorare in tempo reale lo stato di un sistema, sia per poter e�ettuare senza er-
rori gli studi di capacity planning. Questa pratica industriale deve essere capace di
stimare il più precisamente possibile le reali capacità elaborative di un sistema al
crescere del throughput, in modo da poterlo dimensionare correttamente. Si è visto
che fare uno studio di capacity planning basandosi sulle previsioni della metrica di
utilizzo tradizionale è risultato essere molto rischioso. Infatti non si riesce più a
stimare l'utilizzo tradizionale mediante l'Utilization Law, in quanto esso presenta un
andamento non lineare che si discosta nettamente dalla retta di previsione. Questo
problema è molto sentito nell'ambiente industriale che si occupa di studiare le per-
formance, e trovare una metrica che possa migliorare le previsioni è sicuramente un
traguardo innovativo.
Sono stati svolti molteplici test, utilizzando tre di�erenti benchmark, per con-
frontare la bontà della productivity rispetto all'utilizzo tradizionale. Conoscendo
quindi le caratteristiche hardware del sistema e del software che vi era in esecuzione,
la productivity si è rivelata essere una metrica molto più a�dabile rispetto all'u-
tilizzo tradizionale. In particolare si sono ottenuti ottimi risultati nell'e�ettuare la
previsione della capacità del sistema al crescere del throughput. Questo è possibile
grazie al fatto che la productivity ha un andamento lineare che viene correttamente
stimato da una regressione lineare.
La trattazione è stata introdotta da una panoramica sullo stato dell'arte delle
moderne tecnologie dei processori (tra le quali i multiprocessori, i processori multi
core, il Simultaneous multithreading e il Dynamic frequency scaling), seguita dal-
119
Conclusioni
le metriche alternative e dalle critiche alle metriche tradizionali, che sono state la
motivazione alla base di questo studio.
Il modello proposto è un punto di partenza da cui procedere per e�ettuare studi
più approfonditi che tengano in considerazione aspetti di�erenti rientranti nel campo
di studio delle performance. Si segnalano diversi aspetti che possono proseguire il
lavoro svolto in questa tesi:
� Applicare il modello di productivity ai dati raccolti in ambienti di produzione
industriale, con particolare riferimento a server di fascia enterprise su cui sono
eseguiti applicativi business.
� Utilizzare il modello di productivity all'interno degli studi di performance e di
capacity planning, come metrica a supporto e confronto delle analisi eseguite
tramite il modello tradizionale di utilizzo.
� Studiare un modello a reti di code per riuscire a modellizzare l'andamento dei
tempi di risposta, in modo da ottenere i valori di productivity che rispettino i
limiti imposti dalla Quality of Service.
� Indagare su come possa essere migliorata ulteriormente la stima degli IPC del
processore quando si hanno a disposizione dati di un sistema con poco carico
di lavoro.
� Migliorare la suite di tool MTperf, implementando eventualmente un tool che
esegua una reportistica del sistema in tempo reale.
120
Bibliogra�a
[1] Asus. Asus K56CB, 2013 (acceduto il 5 Marzo 2016). https://www.asus.com/
Notebooks/K56CB/specifications/.
[2] Emmanuel Cecchet. RUBBoS: Bulletin Board Benchmark, 2005 (acceduto il 15
Febbraio 2016). http://jmob.ow2.org/rubbos.html.
[3] Emmanuel Cecchet. RUBiS: Rice University Bidding System, 2008 (acceduto il
5 Marzo 2016). http://rubis.ow2.org/.
[4] D. Cerotti, M. Gribaudo, P. Piazzolla, and G. Serazzi. Flexible cpu provisio-
ning in clouds: A new source of performance unpredictability. Quantitative
Evaluation of Systems, pages 230�237, 2012. http://dx.doi.org/10.1109/
QEST.2012.23.
[5] Adrian Cockcroft. Utilization is Virtually Useless as a Metric!, 2006 (acce-
duto il 15 Febbraio 2016). http://www.hpts.ws/papers/2007/Cockcroft_
CMG06-utilization.pdf.
[6] Intel Corporation. Performance Insights to Intel Hyper-Threading Technology,
2009 (acceduto il 15 Febbraio 2016). https://software.intel.com/en-us/
articles/performance-insights-to-intel-hyper-threading-technology.
[7] Intel Corporation. Intel PCM Column Names Decoder Ring, 2014 (acceduto il
22 Febbraio 2016). https://software.intel.com/en-us/blogs/2014/07/18/
intel-pcm-column-names-decoder-ring.
[8] Intel Corporation. Intel Performance Counter Monitor - A better way to mea-
sure CPU utilization, 2015 (acceduto il 22 Febbraio 2016). https://software.
intel.com/en-us/articles/intel-performance-counter-monitor.
[9] Intel Corporation. Intel 64 and IA-32 Architectures Software Developer's Ma-
nuals, 2016 (acceduto il 17 Febbraio 2016). http://www.intel.com/content/
www/us/en/processors/architectures-software-developer-manuals.
html.
121
Bibliogra�a
[10] Intel Corporation. Tecnologia Intel Turbo Boost 2.0, 2016 (accedu-
to il 17 Febbraio 2016). http://www.intel.it/content/www/it/it/
architecture-and-technology/turbo-boost/turbo-boost-technology.
html.
[11] Standard Performance Evaluation Corporation. SPECpower_ssj 2008, 2008
(acceduto il 15 Febbraio 2016). https://www.spec.org/power_ssj2008/.
[12] Steve Daily. Software Design Issues for Multi-core/Multiprocessor
Systems, 2006 (acceduto il 21 Febbraio 2016). http://
www.embedded.com/design/mcus-processors-and-socs/4006624/
Software-Design-Issues-for-Multi-core-Multiprocessor-Systems.
[13] Christian De Looper. All About Multi-Core Processors: What They Are, How
They Work, And Where They Came From, 2015 (acceduto il 21 Febbraio 2016).
http://www.pcmech.com/article/all-about-multi-core-processors-
what-they-are-how-they-work-and-where-they-came-from/.
[14] Peter J. Denning and Je�rey P. Buzen. The operational analysis of queueing
network models. ACM Computing Surveys, 10(3):225�261, 1978. http://dx.
doi.org/10.1145/356733.356735.
[15] Saravanan Devendran. Understanding CPU utilization on AIX, 2015 (acceduto
il 25 Febbraio 2016). https://www.ibm.com/developerworks/community/
wikis/home?lang=en#!/wiki/Power%20Systems/page/Understanding%
20CPU%20utilization%20on%20AIX.
[16] Domenico Ferrari and Songnian Zhou. An empirical investigation of load indices
for load balancing applications. Proceedings of the 12th Int'l Symp. On Compu-
ter Performance Modeling, Measurement, and Evaluation, pages 515�528, 1988.
http://dl.acm.org/citation.cfm?id=725013.
[17] gar�3ld. Intel i5-2500K Sandy Bridge, 2011 (acceduto il 21 Febbraio 2016).
http://lanoc.org/review/energy-items/4638-intel-i5-2500k-sandy.
[18] Francesco Giglioli and Stefano Doni. MTperf, 2015 (acceduto il 1 Marzo 2016).
https://github.com/stefanodoni/mtperf.
[19] Francesco Giglioli and Stefano Doni. MTperf, 2015 (acceduto il 1 Marzo 2016).
https://github.com/giglio91/mtperf.
[20] Neil Gunther. Monitoring CPU Utilization Under Hyper-threading, 2014 (ac-
ceduto il 17 Febbraio 2016). http://perfdynamics.blogspot.it/2014/01/
monitoring-cpu-utilization-under-hyper.html.
122
Bibliogra�a
[21] Intel. Intel Core i7-2600K Processor, 2011 (acceduto il 5
Marzo 2016). http://ark.intel.com/it/products/52214/
Intel-Core-i7-2600K-Processor-8M-Cache-up-to-3_80-GHz.
[22] Intel. Intel Core i7-3537U Processor, 2013 (acceduto il
5 Marzo 2016). http://ark.intel.com/products/72054/
Intel-Core-i7-3537U-Processor-4M-Cache-up-to-3_10-GHz.
[23] J. R. Jackson. Networks of waiting lines. Operations Research, 5(4):518�521,
1957. http://dx.doi.org/10.1287/opre.5.4.518.
[24] Kernel.org. Intel P-State driver, 2016 (acceduto il 17 Febbraio 2016). https:
//www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt.
[25] Andi Kleen. pmu-tools, 2016 (acceduto il 22 Febbraio 2016). https://github.
com/andikleen/pmu-tools.
[26] E. D. Lazowska, J. Zahorjan, G. S. Graham, and K.C. Sevcik. Quantitative
System Performance. Prentice-Hall, 1984.
[27] Michael Mior. Updates to the RUBBoS database benchmark, 2014 (acceduto il
15 Febbraio 2016). https://github.com/michaelmior/RUBBoS.
[28] Joerg Moellenkamp. Measurement artifact, 2012 (acceduto il 24 Febbraio 2016).
http://www.c0t0d0s0.org/archives/7494-Artifact-of-measuring.html.
[29] Oracle. SPARC T4 Supplement, 2012 (acceduto il 24 Febbraio 2016). http:
//www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/
documentation/120214-t4-d04-hp-ext-performance-2307329.pdf.
[30] Oracle. pgstat, 2016 (acceduto il 24 Febbraio 2016). http://docs.oracle.com/
cd/E23824_01/html/821-1462/pgstat-1m.html.
[31] perfmon2. perfmon2, the hardware-based performance monitoring interface for
Linux, 2016 (acceduto il 22 Febbraio 2016). http://perfmon2.sourceforge.
net/.
[32] Pietro Piazzolla, Marco Gribaudo, and Giuseppe Serazzi. jbm - a cpu ben-
chmarking tool for cloud environments. Proceedings of the 6th Internatio-
nal ICST Conference on Simulation Tools and Techniques, pages 57�62, 2013.
http://dx.doi.org/10.4108/icst.simutools.2013.251751.
[33] Puvichakravarthy Ramachandran. Processor Utilization, 2013 (acceduto il 25
Febbraio 2016). https://www.ibm.com/developerworks/community/wikis/
home?lang=en#!/wiki/Power+Systems/page/Processor+Utilization.
123
Bibliogra�a
[34] Matthew Robben. Interpreting CPU Utilization for Perfor-
mance Analysis, 2009 (acceduto il 15 Febbraio 2016). http:
//blogs.technet.com/b/winserverperformance/archive/2009/08/06/
interpreting-cpu-utilization-for-performance-analysis.aspx.
[35] Daniel Rosa. IBM z Systems z13 Simultaneous Multi-Threading (R)Evolution,
2015 (acceduto il 15 Febbraio 2016). https://share.confex.com/share/
124/webprogram/Handout/Session16930/SHARE_IBM_z_Systems_z13%
20Simultaneous_MultiThreading_(R)Evolution.pdf.
[36] Cristina Silvano. Slide del corso "Advanced Computer Architectures", 2015.
Politecnico di Milano.
[37] Jaime Spacco and William Pugh. Rubis revisited: why j2ee benchmarking
is hard. Proceedings of OOPSLA '04 Companion to the 19th annual ACM
SIGPLAN conference on Object-oriented programming systems, languages, and
applications, pages 204�205, 2004. http://dx.doi.org/10.1145/1028664.
1028751.
[38] Ravindra Talashikar. UltraSPARC T1 utilization explained, 2005 (acceduto
il 15 Febbraio 2016). https://blogs.oracle.com/travi/entry/ultrasparc_
t1_utilization_explained.
[39] Martin Tegtmeier. CPU utilization of multi-threaded architectures explai-
ned, 2015 (acceduto il 15 Febbraio 2016). https://blogs.oracle.com/
partnertech/entry/cpu_utilization_of_multi_threaded.
[40] VMware. vSphere Monitoring and Performance, 2015 (acceduto il 26 Febbraio
2016). https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/
PDF/vsphere-esxi-vcenter-server-60-monitoring-performance-guide.
pdf.
[41] Wikipedia. M/M/1 queue, 2016 (acceduto il 21 Febbraio 2016). https://en.
wikipedia.org/wiki/M/M/1_queue.
[42] Wikipedia. Parallel computing, 2016 (acceduto il 21 Febbraio 2016). https:
//en.wikipedia.org/wiki/Parallel_computing.
[43] Zpan. Interpreting esxtop Statistics, 2010 (acceduto il 15 Febbraio 2016). https:
//communities.vmware.com/docs/DOC-9279.
124
top related