dipartimento di elettronica, informazione e bioingegneria ... · l'analisi e la stima delle...

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.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.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.5 Esperimenti con SPECpower_ssj 2008 . . . . . . . . . . . . . . . . . 101





5.5.3 Esperimenti con HT e TB non attivi . . . . . . . . . . . . . . 106


iii

Indice


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.26 SPECpower TC8: R vs U . . . . . . . . . . . . . . . . . . . . . . . . 113



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.4 RUBBoS TC3: performance . . . . . . . . . . . . . . . . . . . . . . . 84


5.6 RUBBoS TC4: TB o� . . . . . . . . . . . . . . . . . . . . . . . . . . 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.18 SPECpower TC3: performance . . . . . . . . . . . . . . . . . . . . . 107

5.19 SPECpower TC6: powersave . . . . . . . . . . . . . . . . . . . . . . 109


5.21 SPECpower TC6: Service Demand . . . . . . . . . . . . . . . . . . . 112

5.22 SPECpower TC8: performance . . . . . . . . . . . . . . . . . . . . . 112


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


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


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


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


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


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


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


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


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.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


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


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


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


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


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


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


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


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


Figura 1.16: Esempio di schermata del tool Top.

25


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


Figura 1.17: Esempio di schermata del tool Vmstat.

Figura 1.18: Esempio di schermata del tool Turbostat.

27


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


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


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


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


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


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


� 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


� 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


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


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


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


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


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


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


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


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


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.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.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


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).


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


� 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:


Intel SandyBridge and IvyBridge Architectures

elif system_config['Model '] == 26 or system_config['Model ']

== 30 or system_config['Model'] == 46:


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.


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


� 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







# 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


� 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


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


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


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


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


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


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


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


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


Tabella 5.4: RUBBoS TC3: risultati dell'esperimento sul sistema in con�gurazionestandard (governor performance).


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


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


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


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


0 200 400 600 800 1000 1200 1400

Throughput

0

20

40

60

80

100

Pro

duct

ivit


RUBBoS BenchmarkSUT: HT on, TB off, Governor performance


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


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


Tabella 5.6: RUBBoS TC4: risultati dell'esperimento in cui il sistema ha il TBdisattivo.


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


Tabella 5.8: RUBBoS TC7: risultati dell'esperimento in cui il sistema ha l'HTdisattivo.


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


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


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


0 200 400 600 800 1000 1200 1400

Throughput

0

20

40

60

80

100

Uti

lizzo

Tra

dizi

onal


RUBBoS BenchmarkSUT: HT off, TB on, Governor performance


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


0 200 400 600 800 1000 1200 1400

Throughput

0

20

40

60

80

100

Pro

duct

ivit


RUBBoS BenchmarkSUT: HT off, TB on, Governor performance


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


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


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


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


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


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


0 500 1000 1500

Throughput

0

20

40

60

80

100

Pro

duct

ivit




Figura 5.14: RUBBoS Frequenze Crescenti: analisi di Productivity controThroughput, sistema in con�gurazione standard.


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


0 500 1000 1500

Throughput

1.0

1.2

1.4

1.6

1.8

2.0

Ave

rage

Thr

ead

Den

sity


SUT: HT on, TB on, Governor performance


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


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.


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.


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


0 50 100 150 200 250 300 350 400

Throughput

0

20

40

60

80

100

Uti

lizzo

Tra

dizi

onal


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


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


0 50 100 150 200 250 300 350 400

Throughput

0

20

40

60

80

100

Pro

duct

ivit


CBench BenchmarkSUT: HT on, TB on, Governor powersave


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


Tabella 5.12: CBench TC1: risultati dell'esperimento sul sistema in con�gurazionestandard (governor powersave).


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


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


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


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


0 20 40 60 80 100


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.


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


Tabella 5.13: CBench TC3: risultati dell'esperimento sul sistema in con�gurazionestandard (governor performance).


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


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.


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.


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


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


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


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


0 20000 40000 60000 80000 100000 120000 140000 160000

Throughput

0

20

40

60

80

100

Pro

duct

ivit


SPECpower ssj 2008 BenchmarkSUT: HT on, TB on, Governor powersave


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.


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


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


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


Tabella 5.16: SPECpower TC1: risultati dell'esperimento sul sistema incon�gurazione standard (governor powersave).


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


Tabella 5.18: SPECpower TC3: risultati dell'esperimento sul sistema incon�gurazione standard (governor performance).


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


0 20000 40000 60000 80000 100000 120000 140000 160000

Throughput

0

20

40

60

80

100

Uti

lizzo

Tra

dizi

onal


SPECpower ssj 2008 BenchmarkSUT: HT on, TB on, Governor performance


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.


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


Tabella 5.19: SPECpower TC6: risultati dell'esperimento sul sistema con HT o�,TB o� e governor powersave.


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


� 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


0 20000 40000 60000 80000 100000 120000

Throughput

0

20

40

60

80

100

Pro

duct

ivit


SPECpower ssj 2008 BenchmarkSUT: HT off, TB off, Governor powersave


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.


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


0 20000 40000 60000 80000 100000 120000

Throughput

0

20

40

60

80

100

Uti

lizzo

Tra

dizi

onal


SPECpower ssj 2008 BenchmarkSUT: HT off, TB off, Governor powersave


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


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.


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


0 20 40 60 80 100


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


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


0 20000 40000 60000 80000 100000 120000

Throughput

0

20

40

60

80

100

Uti

lizzo

Tra

dizi

onal


SPECpower ssj 2008 BenchmarkSUT: HT off, TB off, Governor performance


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


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)



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


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


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

https://www.asus.com/Notebooks/K56CB/specifications/

https://www.asus.com/Notebooks/K56CB/specifications/

http://jmob.ow2.org/rubbos.html

http://rubis.ow2.org/

http://dx.doi.org/10.1109/QEST.2012.23

http://dx.doi.org/10.1109/QEST.2012.23

http://www.hpts.ws/papers/2007/Cockcroft_CMG06-utilization.pdf

http://www.hpts.ws/papers/2007/Cockcroft_CMG06-utilization.pdf

https://software.intel.com/en-us/articles/performance-insights-to-intel-hyper-threading-technology

https://software.intel.com/en-us/articles/performance-insights-to-intel-hyper-threading-technology

https://software.intel.com/en-us/blogs/2014/07/18/intel-pcm-column-names-decoder-ring

https://software.intel.com/en-us/blogs/2014/07/18/intel-pcm-column-names-decoder-ring

https://software.intel.com/en-us/articles/intel-performance-counter-monitor

https://software.intel.com/en-us/articles/intel-performance-counter-monitor

http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html



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

http://www.intel.it/content/www/it/it/architecture-and-technology/turbo-boost/turbo-boost-technology.html



https://www.spec.org/power_ssj2008/

http://www.embedded.com/design/mcus-processors-and-socs/4006624/Software-Design-Issues-for-Multi-core-Multiprocessor-Systems



http://www.pcmech.com/article/all-about-multi-core-processors-what-they-are-how-they-work-and-where-they-came-from/

http://www.pcmech.com/article/all-about-multi-core-processors-what-they-are-how-they-work-and-where-they-came-from/

http://dx.doi.org/10.1145/356733.356735

http://dx.doi.org/10.1145/356733.356735

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/Understanding%20CPU%20utilization%20on%20AIX



http://dl.acm.org/citation.cfm?id=725013

http://lanoc.org/review/energy-items/4638-intel-i5-2500k-sandy

https://github.com/stefanodoni/mtperf

https://github.com/giglio91/mtperf

http://perfdynamics.blogspot.it/2014/01/monitoring-cpu-utilization-under-hyper.html

http://perfdynamics.blogspot.it/2014/01/monitoring-cpu-utilization-under-hyper.html

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

http://ark.intel.com/it/products/52214/Intel-Core-i7-2600K-Processor-8M-Cache-up-to-3_80-GHz

http://ark.intel.com/it/products/52214/Intel-Core-i7-2600K-Processor-8M-Cache-up-to-3_80-GHz

http://ark.intel.com/products/72054/Intel-Core-i7-3537U-Processor-4M-Cache-up-to-3_10-GHz

http://ark.intel.com/products/72054/Intel-Core-i7-3537U-Processor-4M-Cache-up-to-3_10-GHz

http://dx.doi.org/10.1287/opre.5.4.518

https://www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt

https://www.kernel.org/doc/Documentation/cpu-freq/intel-pstate.txt

https://github.com/andikleen/pmu-tools

https://github.com/andikleen/pmu-tools

https://github.com/michaelmior/RUBBoS

http://www.c0t0d0s0.org/archives/7494-Artifact-of-measuring.html

http://www.oracle.com/technetwork/server-storage/sun-sparc-enterprise/documentation/120214-t4-d04-hp-ext-performance-2307329.pdf



http://docs.oracle.com/cd/E23824_01/html/821-1462/pgstat-1m.html

http://docs.oracle.com/cd/E23824_01/html/821-1462/pgstat-1m.html

http://perfmon2.sourceforge.net/

http://perfmon2.sourceforge.net/

http://dx.doi.org/10.4108/icst.simutools.2013.251751

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power+Systems/page/Processor+Utilization

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power+Systems/page/Processor+Utilization

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

http://blogs.technet.com/b/winserverperformance/archive/2009/08/06/interpreting-cpu-utilization-for-performance-analysis.aspx



https://share.confex.com/share/124/webprogram/Handout/Session16930/SHARE_IBM_z_Systems_z13%20Simultaneous_MultiThreading_(R)Evolution.pdf



http://dx.doi.org/10.1145/1028664.1028751

http://dx.doi.org/10.1145/1028664.1028751

https://blogs.oracle.com/travi/entry/ultrasparc_t1_utilization_explained

https://blogs.oracle.com/travi/entry/ultrasparc_t1_utilization_explained

https://blogs.oracle.com/partnertech/entry/cpu_utilization_of_multi_threaded

https://blogs.oracle.com/partnertech/entry/cpu_utilization_of_multi_threaded

https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-monitoring-performance-guide.pdf



https://en.wikipedia.org/wiki/M/M/1_queue

https://en.wikipedia.org/wiki/M/M/1_queue

https://en.wikipedia.org/wiki/Parallel_computing

https://en.wikipedia.org/wiki/Parallel_computing

https://communities.vmware.com/docs/DOC-9279

https://communities.vmware.com/docs/DOC-9279

dipartimento di elettronica, informazione e bioingegneria ... · l'analisi e la stima delle...

Documents