Your SlideShare is downloading. ×
Monitoraggio di applicazioni software mediante modelli di Markov
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Monitoraggio di applicazioni software mediante modelli di Markov

1,013

Published on

tesi di laurea - Riccardo Cecolin

tesi di laurea - Riccardo Cecolin

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,013
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ` Universita Degli Studi di Trieste ` Facolta di Ingegneria Dipartimento di Elettrotecnica, Elettronica ed Informatica Tesi di Laurea in Sistemi Operativi Monitoraggio di applicazioni software mediante modelli di MarkovLaureando : Relatore :Riccardo CECOLIN Chiar.mo Prof. Enzo MUMOLO Anno Accademico 2009-2010
  • 2. Indice1 Introduzione 7 1.1 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 92 Concetti preliminari 11 2.1 Prestazioni di un sistema di calcolo . . . . . . . . . . . . . . . 11 2.2 Tracce di indirizzi . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Parametrizzazione delle tracce . . . . . . . . . . . . . . . . . . 13 2.4 I Modelli di Markov Nascosti . . . . . . . . . . . . . . . . . . 163 Valgrind 19 3.1 Coregrind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3 Cachegrind, analisi di un tool . . . . . . . . . . . . . . . . . . 21 3.4 Sviluppo di un Tool . . . . . . . . . . . . . . . . . . . . . . . 22 3.5 Modifiche a Coregrind . . . . . . . . . . . . . . . . . . . . . . 23 3.5.1 Wrapper interno . . . . . . . . . . . . . . . . . . . . . 24 3.5.2 Thread wrapper . . . . . . . . . . . . . . . . . . . . . 24 3.5.3 Thread injection . . . . . . . . . . . . . . . . . . . . . 25 3.5.4 External state . . . . . . . . . . . . . . . . . . . . . . 254 Spec 27 4.1 CPU2006 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.1 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.2 Speed Ratio . . . . . . . . . . . . . . . . . . . . . . . . 28 4.1.3 Throughput Ratio . . . . . . . . . . . . . . . . . . . . 28 4.2 Misurazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3 Configurazione . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4 Esecuzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5 Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.5.1 401.bzip2 . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.5.2 445.gobmk . . . . . . . . . . . . . . . . . . . . . . . . 31 4.5.3 458.sjeng . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.5.4 403.gcc . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3
  • 3. 4.5.5 464.h264ref . . . . . . . . . . . . . . . . . . . . . . . . 32 4.5.6 400.perlbench . . . . . . . . . . . . . . . . . . . . . . . 32 4.5.7 429.mcf . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.5.8 462.libquantum . . . . . . . . . . . . . . . . . . . . . . 32 4.5.9 456.hmmer . . . . . . . . . . . . . . . . . . . . . . . . 33 4.5.10 471.omnetpp . . . . . . . . . . . . . . . . . . . . . . . 33 4.5.11 473.astar . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.5.12 483.xalancbmk . . . . . . . . . . . . . . . . . . . . . . 335 Analisi delle tracce di indirizzi 35 5.1 Addestramento hmm . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 Test hmm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.3 Addestramento reti neurali . . . . . . . . . . . . . . . . . . . 38 5.4 Test reti neurali . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5 Analisi offline . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5.1 Hmm . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.5.2 Reti neurali . . . . . . . . . . . . . . . . . . . . . . . . 40 5.6 Analisi con Valgrind . . . . . . . . . . . . . . . . . . . . . . . 40 5.6.1 Tracehmm . . . . . . . . . . . . . . . . . . . . . . . . . 416 Risultati sperimentali 45 6.1 Risultati test offline . . . . . . . . . . . . . . . . . . . . . . . 46 6.1.1 Test di verifica hmm . . . . . . . . . . . . . . . . . . . 46 6.1.2 Test di verifica reti neurali . . . . . . . . . . . . . . . . 47 6.2 Analisi su Valgrind . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2.1 Test di verifica . . . . . . . . . . . . . . . . . . . . . . 50 6.2.2 Test di classificazione . . . . . . . . . . . . . . . . . . 507 Applicazioni 63 7.1 Monitoraggio e sicurezza . . . . . . . . . . . . . . . . . . . . . 63 7.1.1 Whitelist . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.1.2 Blacklist . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.2 Allocazione di risorse . . . . . . . . . . . . . . . . . . . . . . . 64 7.2.1 Sistemi operativi . . . . . . . . . . . . . . . . . . . . . 64 7.2.2 Ambienti di virtualizzazione . . . . . . . . . . . . . . . 64 7.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.1 User space . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3.2 Kernel space . . . . . . . . . . . . . . . . . . . . . . . 66 7.3.3 Virtualizzazione . . . . . . . . . . . . . . . . . . . . . 668 Conclusione 69 4
  • 4. A Documentazione tools offline 71 A.1 train, test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 A.2 genset zero, genset one, ntrain, ntest . . . . . . . . . . . . . . 72B Documentazione tools Valgrind 73 B.1 tracebin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 B.2 tracehmm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5
  • 5. 6
  • 6. Capitolo 1IntroduzioneIl problema principale affrontato in questa tesi ` quello della classificazione edei processi in esecuzione su un calcolatore. Pi` precisamente usando misure ueffettuate sul processo in esecuzione, nel nostro caso gli indirizzi virtuali diaccesso in memoria, sono stati addestrati dei modelli statistici di tipo Marko-viano che descrivono il processo e che consentono di riconoscerlo durante lasua esecuzione. Il problema affrontato si inquadra nel campo generale della Modellazionedel carico di lavoro (Workload Modeling) che ` un argomente trattato nella eIngegneria del Software. Lo scopo del Workload Modeling ` quello di fornire edegli strumenti che portino a migliorare le prestazioni dei sistemi di calcolo.Ad esempio, se si riesce a riconoscere che una applicazione in esecuzionerichieder` determinate risorse, si pu` agevolare l’esecuzione preallocando le a orisorse richieste. La motivazione di questo lavoro ` sia quella di definire degli algoritmi per eoperare classificazioni dei processi in esecuzione, sia quella di realizzare delleoperazioni di tuning del sistema adattandolo ai carichi di lavoro usualmentesopportati. Un ulteriore obiettivo ` quello di implementare delle metodologie edi adattamento dinamico al workload in esecuzione, ottimizzando i sistemipur conservandone la flessibilit`. L’approccio adottato ` quello di model- a elare la sequenza di indirizzi virtuali con un Modello di Markov Nascostoopportunamente adattato all’impiego. Una branca dell’Ingegneria del Software si occupa di questo tipo dianalisi: accanto agli sforzi per progettare un software che ben si adattaa una specifica architettura hardware si possono aggiungere quelli per pro-gettare una certa architettura ottimizzata rispetto ai compiti che questa sar` achiamata a svolgere durante il suo impiego. Accanto a questo livello di progetto si affianca poi un livello diretta-mente superiore che consiste nel progetto del nucleo del S.O. che permetter` adi gestire efficacemente questi carichi di lavoro: gestione dell’I/O su dis-co, gestione delle risorse di memoria, gestione delle sincronizzazione IPC, 7
  • 7. gestione del networking, ecc. Ecco quindi nascere la necessit` di sapere il tipo di carichi in gioco e ala possibilit` di modellare questi workload con degli strumenti che ci per- amettono poi di implementare schemi di design e tuning del sistema hard-ware/software che materialmente eseguir` il compito richiesto. a Un altro obiettivo dell’Ingegneria del Software a cui ci si avvicina par-lando di classificazione di workload ` quello della misura delle prestazioni di euna CPU. Anche in questo senso le aspettative sono ampie: identificazionedi aree di sviluppo e incremento di prestazioni, monitoraggio di richieste dirisorse, identificazione di colli di bottiglia del software.Il problemaLa classificazione dei workload non ` un’operazione semplice perch` presup- e epone di poter accedere a informazioni sul processo che spesso non possiamoreperire senza turbare l’esecuzione stessa del processo. Sviluppare degli stru-menti software che monitorizzano alcuni parametri di esecuzione di work-load pu` essere molto difficile, fermo restando sempre il pericolo di falsare la omisura che si sta operando. L’idea quindi ` di usare delle metriche di misura eche non turbino l’esecuzione e che possano essere facilmente elaborate, suc-cessivamente, per un’analisi e uno studio a posteriori. A questo scopo unametodologia che sembra opportuna ` quella di estrarre delle informazioni su etipo e quantit` di richiesta di risorse di memoria durante l’esecuzione di un aprocesso, cio` quella di estrarre da un processo in esecuzione la sequenza edegli indirizzi virtuali, che possono costituire tracce di indirizzi. Questeinformazioni possono essere memorizzate su memorie di massa e rese dipubblico dominio, come fatto da diverse organizzazioni come il PerformanceEvaluation Laboratory della Brigham Young University.L’obiettivoUn obiettivo di questa tesi ` quello di verificare se la sequenza degli indirizzi evirtuali pu` essere utilizzata per classificare un processo in esecuzione e con oche accuratezza. Se la classificazione ` possibile, vogliono esaminare due estrade: una ` quella di classificare un processo e l’altra ` quella di verificare e eil processo, cio` di verificare che un processo sia quello che dichiara di essere. e L’approccio seguito ` stato quello di supporre che i workload possano eessere descritti da un punto di vista statistico come processi di Markov.Si sono quindi usate librerie che realizzano Modelli di Markov di tipo dis-creto che ci hanno permesso di operare delle classificazioni considerando ilworkload nel suo complesso. In accordo con i lavori [1], [2] e [3], abbiamopensato di analizzare metriche di memoria per individuare le tipologie localidei workload. 8
  • 8. 1.1 Struttura della tesiI capitoli si articolano nel modo seguente:Capitolo 2 Prestazioni di un sistema di calcolo in particolare in riferimento agli accessi in memoria.Capitolo 3 Struttura di Valgrind, framework di instrumentazione per lo sviluppo di strumenti di analisi dinamica.Capitolo 4 Analisi di SPEC CPU2006, suite di benchmark standard per valutare processore, memoria e compilatore di un sistema.Capitolo 5 Analisi, classificazione e verifica delle tracce di indirizzi e doc- umentazione dei tool sviluppati.Capitolo 6 Presentazione e discussione dei pi` importanti risultati sper- u imentali conseguiti nella classificazione di tracce di processi e nella classificazione di workload.Capitolo 7 Applicazioni pratiche del tool sviluppato e possibili modalit` a di messa in atto in sistemi in stato di produzione.Capitolo 8 Considerazioni finali che riassumono il lavoro svolto. 9
  • 9. 10
  • 10. Capitolo 2Concetti preliminari2.1 Prestazioni di un sistema di calcoloLa performance di un sistema si pu` definire come la capacit` del sistema o adi eseguire un compito, o workload, in relazione a determinati parametri.La performance pu` essere valutata in termini misurabili utilizzando diverse ometodologie: in relazione al tempo impiegato per completare un determinatoprocesso, ai watt consumati, al tempo di risposta. Gli obiettivi di unamisurazione possono essere di rilevare differenze nel sistema prima e dopodelle modifiche o di confrontare il sistema con altri. Per poter avere dei risultati comparabili tra architetture diverse cheeseguono software differente sono stati sviluppati dei benchmarks, i qualiforniscono un dato misurabile ed oggettivo delle capacit` di un macchina. aI benchmark pi` diffusi sono SPEC sviluppato da Standard Performance uEvaluation Corporation e ConsumerMark sviluppato da EEMBC, Em-bedded Microprocessor Benchmark Consortium. Ogni benchmark fornisceun workload in modo deterministico che quindi pu` essere utilizzato per mis- ourare la capacit` di calcolo intero, floating point, di input/output, di banda adi accesso alla memoria del sistema in esame. I benchmark valutano l’ese-cuzione di questo workload con un numero che pu` quindi essere rapportato oad altri sistemi/architetture. Un fattore significativo per la misura e la caratterizzazione di un work-load ` dato dalla sequenza di indirizzi corrispondenti agli accessi in memoria e[4]. Questo valore pu` essere utilizzato per calcolare la frequenza di miss osulle memorie cache del sistema o per misurare la localit` spaziale delle aistruzioni o dei dati. In Fig. 2.1 ` riportata l’analisi di cache miss rate di edati e istruzioni di un processo (bzip2) in diversi momenti della sua ese-cuzione. Su una macchina moderna, un cache L1 miss pu` significare 10 ocicli di cpu persi, un cache L2 miss fino a 200. Un cache profiling adeguatopu` rivelarsi estremamente utile per capire come ottimizzare l’esecuzione di oun’applicazione. Una configurazione tipica attuale ` data da una cache di e 11
  • 11. livello 1 con istruzioni e dati separati (I1, D1) e una cache di livello 2 unifi-cata (I2 + D2). Per ottenere dati dettagliati sui rapporti miss/request delle Figura 2.1: Cache miss rate durante una esecuzione di bzip2memorie cache si fa uso di simulatori, i quali propongono un modello di ger-archia di memoria il pi` simile possibile a quello delle architetture reali cos` u ıda fornire dei dati attendibili per risolvere problemi di performance dovu-ti agli accessi alla memoria. I simulatori di memoria cache leggono comeinput tracce di indirizzi, ovvero dei file contenenti la sequenza di indirizzicorrispondenti accessi in memoria effettuati durante l’esecuzione.2.2 Tracce di indirizziLe tracce posso essere sia file di testo ascii sia binari, tipicamente oltreagli indirizzi sono riportate anche delle informazioni ulteriori riguardantiogni singolo accesso in memoria: dimensione in byte dell’accesso, modalit`alettura/scrittura... Un formato comunemente utilizzato ` quello prodotto edal tool lackey presente nel framework Valgrind, che genera tracce ascii nelformato qui commentato:I 0023C790,2 # instruction read all’indirizzo 0x0023C790S BE80199C,4 # data store di 4 byte all’indirizzo 0xBE80199CL BE801950,4 # data load di 4 byte all’indirizzo 0xBE801950M 0025747C,1 # data modify di 1 byte all’indirizzo 0x0025747CIn lackey lettura e scrittura di una stessa locazione in modo consecutivo sonoriportate come data modify. Altri formati di tracce sono quelli definiti dal 12
  • 12. simulatore di memorie cache dinero, che prevede sia formati ascii simili aquello di lackey sia un formato binario che permette di risparmiare spaziosu disco, importante in quanto le tracce possono raggiungere dimensioninotevoli. Questi formati sono, in caso di sistema a 32bit:traditional compatibile anche con dineroIII, ` un formato ascii definito e C AAAAAAAA con C modalit` di accesso e i campi A per l’indirizzo. a 2 04000850 2 04000852 1 be8f1f4cextended include anche informazioni sulla dimensione in byte dell’accesso alla memoria, C AAAAAAAA SS con SS dimensione in byte dell’accesso i 04000850 2 i 04000852 5 r bec3446c 4 i 04000a90 1 w bec34468 4binary vengono memorizzati 8 byte per accesso, AAAASSCP AAAA indirizzo SS dimensione dell’accesso C modalit` (read,write,instruction fetch-0,1,2) a P byte di paddingNel caso delle tracce ascii per la conversione da un formato all’altro ` stato esviluppato uno script sed:#!/usr/bin/sed/^=/ds/,[0-9]+$//s/^Is/2/s/^sS/1/s/^sL/0/s/sMs([0-9a-f]*)/0 1n1 1/2.3 Parametrizzazione delle tracceDalle tracce di accessi in memoria devono essere rimosse le informazioniridondanti ed estratti i tratti principali, riducendo la quantit` di dati da aprocessare. Comportamenti sequenziali o ciclici nell’esecuzione sono di fatto 13
  • 13. inclusi nel dominio spettrale della traccia, quindi si pu` operare una com- opressione in questo dominio mantenendo le informazioni pi` significative. I ucicli per esempio introducono picchi nello spettro mentre una sequenza diindirizzi lineare produrr` una componente continua. Si vogliono utilizzare aquindi strumenti di analisi dei segnali per elabolare la sequenza di indirizzi.Figura 2.2: Spettrogramma di una sequenza di indirizzi contenente cicliannidati La sequenza di indirizzi ` tempo variante, per cui si utilizza un’analisi espettrale a breve termine. Nella fase di apprendimento gli indirizzi ver-ranno divisi in segmenti di lunghezza limitata sui quali verr` applicata la atrasformata discreta del coseno. La DCT ` una operazione comunemente eutilizzata nella trasformazione dei segnali, utile per ridurre la ridondanza inquanto distribuisce pi` energia possibile nei primi coefficienti. Calcolata la uDCT su un certo numero di segmenti vengono presi i primi coefficienti dellaDCT di ogni segmento e su di essi applicata la quantizzazione vettoriale.Il procedimento di quantizzazione vettoriale suddivide lo spazio in settoriad ognuno dei quale associa un vettore centroide, ogni vettore viene quindiassociato al centroide pi` vicino ottenendo un insieme di indici relativi ai ucentroidi. Tali indici sono utilizzati come input per HMM. Utilizzare solo i primi valori della DCT ha l’effetto di approssimare i pic-chi della sequenza originale pur mantenendone il comportamento generale. 14
  • 14. Figura 2.3: La sequenza di vettori di indirizzi viene trasformata in unasequenza di vettori n-dimensionaliFigura 2.4: Viene applicata la quantizzazione vettoriale per trovare icentroidi e di ogni vettore calcolato il centroide pi` vicino u 15
  • 15. 2.4 I Modelli di Markov NascostiUna catena markoviana a tempo discreto ` una sequenza aleatoria qn tale eche la variabile successiva dipende solamente dalla variabile precedente. Ilsistema pu` essere quindi descritto da una sequenza di stati, che corrispon- odono a degli eventi osservabili. Ad ogni istante del tempo discreto il sistemapassa da uno stato all’altro con una certa probabilit` di transizione. a Figura 2.5: Modello di Markov nascosto Lo stato attuale qn riassume quindi la storia del sistema per prevederel’elemento successivo qn+1 . Una catena di Markov ` un modello troppo restrittivo per poter essere eapplicato al problema di interesse. Il modello pu` essere esteso al caso in ocui le osservazioni siano una funzione probabilistica dello stato e quindi nonosservabili direttamente. Le osservazioni sono cio` nascoste. Un modello di eMarkov nascosto ` caratterizzato da: e • il numero di stati N , con l’insieme degli stati S = S1 , .., SN e con qt lo stato al tempo t • il numero di simboli osservati M , ovvero la dimensione dell’alfabeto discreto. Indichiamo l’insieme dei simboli con V = V1 , ..., VM • la matrice di transizione tra stati A = [aij ] dove aij = P [qt+1 = Sj |qt = Si ] 1 ≤ i, j ≤ N ` la probabilit` di passare dallo stato Si allo stato Sj . e a • la distribuzione delle osservazioni nello stato j: bj (k), dove bj (K) = P [Vk |qt = Sj ] 1≤j≤N 1≤k≤M ` la probabilit` di osservare il simbolo Vk se all’istante t il sistema si e a trova nello stato j. 16
  • 16. • il vettore delle probabilit` iniziali π, dove a πj = P [q1 = Sj 1≤j≤N ` la probabilit` che il sistema si trovi all’istante iniziale nello stato Sj e aSi pu` quindi indicare un modello di Markov nascosto con λ = (A, B, π). o Il processo di apprendimento di un modello di Markov implica la ricercadei parametri (A, B, π) tali da massimizzare la probabilit` di riconoscere la asequenza di osservazioni. Poich` non si conosce una soluzione analitica che etrovi un massimo assoluto si utilizza una procedura iterativa. L’algoritmodi Baum-Welch in [5] fa questo in modo efficiente utilizzando soltanto lasequenza di simboli emessi come dati di addestramento. La parte nascostadi un hmm, cio` la sequenza di stati, non pu` essere scoperta, ma pu` essere e o ointerpretata in qualche modo significativo. L’algoritmo di Viterbi in [6]permette di generare la sequenza pi` probabile di stati relativi ad un dato umodello hmm. Inoltre avendo una sequenza di simboli l’algoritmo di Viterbirende possibile verificarne l’affinit` con un modello hmm una calcolandone ala probabilit`. a 17
  • 17. 18
  • 18. Capitolo 3ValgrindPi` i sistemi hardware e software crescono in complessit` pi` si rivelano u a unecessari sistemi per verificarne la correttezza. Per migliorare qualit` e arobustezza dei programmi possono essere utilizzati dei tool di analisi o in-strumentazione. Questi tool effettuano diversi tipi di operazioni per deter-minare informazioni di interesse relative ai programmi. Gli approcci utiliz-zati si possono suddividere in analisi statica e dinamica, analisi dei sorgentio dell’eseguibile binario. Si definisce analisi dinamica di un software l’analisi di questi mentre ` in eesecuzione su un processore reale o virtuale, a differenza dell’analisi staticache si propone di verificare eventuali propriet` del software analizzandone al’object-code compilato o il codice sorgente, senza eseguire il software. I tooldi instrumentazione dinamica permettono di analizzare il 100% del codiceche viene eseguito in user mode senza richiedere accesso al codice sorgentema seguendo soltanto un flusso di esecuzione. I tool di analisi statica per-mettono di seguire tutte le diramazioni del codice ma non hanno accessoallo stato dell’applicazione in esecuzione. I due approcci si possono ritenerecomplementari. I parametri ottenuti dai tool di analisi dinamica riguardano spesso laquantit` memoria utilizzata in varie fasi di esecuzione, le chiamate alle fun- azioni di allocazione/rilascio, errori di scrittura/lettura nei buffer allocati,race conditions nel caso di programmi multithreaded... Tali tool possonoanche dare accesso allo spazio di indirizzamento del processo e ai registridella cpu. Quando un tool di analisi permette di intervallare il proprio codice conquello dell’eseguibile analizzato allora esso si pu` definire tool di instrumen- otazione. Per accedere alla traccia di indirizzi generata da un’applicazione edelaborarla per poter addestrare HMM con essa si ` reso necessario l’utilizzo eun tool di instrumentazione dinamica. Valgrind ` un framework di instrumentazione sul quale ` possibile svilup- e epare tool di analisi dinamica[7]. Valgrind viene distribuito con un insieme 19
  • 19. di tool gi` predisposti per le operazioni pi` comuni di instrumentazione, a uquali gestione di memoria, threading... Il framework offre inoltre un’inter-faccia per poter sviluppare altri tool a seconda dell’esigenza. La natura opensource del framework, distribuito sotto licenza GNU GPLv2, permette an-che di modificare i tool esistenti o perfino il codice sorgente del frameworkstesso, coregrind.3.1 CoregrindIl framework ` progettato [8] per non richiedere una nuova compilazione o elinking delle applicazioni che deve eseguire, permette di analizzare eseguibiligi` esistenti. Passando come parametro a Valgrind il nome dell’eseguibile ada lanciare questo viene caricato in memoria insieme alle librerie ad essoassociate. Le istruzioni del programma vengono tradotte in un linguaggioRISC-like indipendente dall’architettura, chiamato VEX IR, per essere poieseguite su una cpu virtuale. Ogni istruzione tradotta viene passata ad il tool in esecuzione (sceltocome parametro da linea di comando), il quale aggiunge il proprio codicedi instrumentazione, per poi essere simulata. VEX IR ` pi` simile alla rap- e upresentazione del codice com’` organizzata internamente in un compilatore eche ad un linguaggio assemblativo. Le istruzioni VEX sono organizzate inblocchi IRSB che possono contenere da 1 a 50 istruzioni. I blocchi hannoun solo punto di ingresso ma ` possibile che l’esecuzione esca dal blocco da epi` di un punto. u I programmi multi-threaded sono supportati ma l’esecuzione di questi ` eserializzata con un sistema di semafori in modo tale che soltanto un threadvenga eseguito simultaneamente dal core di Valgrind. Lo scheduling deithread viene effettuato dal sistema operativo.3.2 ToolsI tools presenti nella distribuzione ufficiale di Valgrind sono 10: Memcheck,Cachegrind, Callgrind, Helgrind, DRD, Massif, DHAT, Ptrcheck, BBV,Lackey. Memcheck, Massif e DHAT sono tool relativi all’utilizzo della memo-ria dinamica: Memcheck rileva errori nell’accesso alla memoria allocata,mentre Massif e DHAT effettuano analisi sull’utilizzo di questa. Sempre collegato agli accessi in memoria e strettamente orientato all’ot-timizzazione della performance delle applicazioni ` Cachegrind: un simu- elatore di memoria cache che analizzando gli accessi effettuati dal programmaclient riporta informazioni utili per la sua ottimizzazione. 20
  • 20. 3.3 Cachegrind, analisi di un toolL’implementazione di Cachegrind [9] prevede l’aggiunta di codice di instru-mentazione ad ogni accesso in memoria per aggiornare il simulatore di cacheinterno. Ogni istruzione prima di essere eseguita ` tradotta in un linguag- egio RISC intermedio e passata al tool, che controlla se fa riferimenti allamemoria (load/store) o se ` un’istruzione di fetch: in caso positivo la passa eal simulatore. Il modello di memoria implementato in Cachegrind ` configurabile in ealcuni aspetti, fisso in altri. Sono configurabili dimensione totale, dimensionedei blocchi (linee) e associativit`. Il numero e tipo delle memorie invece non alo `, sono presenti due memorie cache L1 indipendenti, una per le istruzione ee una per i dati: Li1, Ld1 e una cache L2 condivisa. Caratteristiche: • Rimpiazzamento LRU • Write-allocate (una miss in scrittura su un dato lo porta in cache L1) • Cache L2 inclusiva • Bit selection hash tableLimiti: • Fa uso di indirizzi virtuali, diversi da quelli che verrebbero inseriti nella cache realmente • Le syscall non vengono tracciate, quindi i riferimenti effettuati in modalit` kernel non hanno effetto a • Gli altri processi in esecuzione non hanno effetto sulla cache simulataLe opzioni per l’inizializzazione della memoria cache simulata devono esserepassate da linea di comando:valgrind --tool=cachegrind [options] ./program--I1=<size>,<associativity>,<line size>--D1=<size>,<associativity>,<line size>--L2=<size>,<associativity>,<line size>--cache-sim=no|yes [yes]--branch-sim=no|yes [no]--cachegrind-out-file=<file>Cachegrind presenta anche una funzionalit` che analizza il numero di branch apredette correttamente dalla cpu, il flag -branch-sim=yes attiva questa fun-zionalit`. Ogni esecuzione di Valgrind produce un file di output, controllato ada -cachegrind-out-file, di default nella forma cachegrind.out.%p con 21
  • 21. %p pid del processo avviato. Questo file pu` essere poi utilizzato da degli oscripts (es. cg_annotate) per produrre statistiche pi` dettagliate. u Il simulatore produce in output numero di reference, miss e miss-rate delfetch di istruzioni, della lettura di dati e della scrittura di dati per entrambii livelli di cache. Per ulteriori analisi ` possibile fare uso di due script dis- etribuiti assieme a cachegrind: cg_merge e cg_annotate. cg_merge permettedi generare i risultati complessivi di esecuzioni multiple della stessa appli-cazione combinando diversi file di log cachegrind.out. cg_annotate analizzain modo molto approfondito i file di log e produce percentuali di cache missrelative ad ogni file, ad ogni funzione o ad ogni singola linea di codice (sel’eseguibile include informazioni di debugging).3.4 Sviluppo di un ToolL’architettura del framework prevede una netta distinzione tra Coregrind ei tool. Coregrind fornisce il supporto all’infrastruttura di instrumentazione,traduzione delle istruzioni, gestione della memoria, scheduling lasciando al-cune operazioni indefinite sotto forma di prototipi di funzioni, che devonoessere implementate nei singoli tool. Coregrind fornisce anche altri serviziai tool che verranno descritti in seguito. I tool vengono compilati insieme a Coregrind per generare un nuovoeseguibile che viene selezionato dal parametro -tool all’avvio di Valgrind.Le funzioni necessarie perch` il tool possa essere compilato correttamente esono:pre_clo_init() E’ disponibile per inizializzare le strutture di memoria in- terne del tool. E’ possibile inoltre dichiarare a quali eventi dell’ese- cuzione il tool ` interessato e registraci delle callback: e track_pre_thread_ll_create, track_new_mem_stack ...post_clo_init() Questa funzione viene chiamata dopo che ` stato effet- e tuato il parsing dei parametri passati da linea di comando per filtrare quelli relativi a coregrind. Va qui effettuato il parsing delle opzioni relative al tool ed ` possibile procede ulteriormente con le operazioni e di inizializzazione.instrument() Ogni volta che l’esecuzione entra in un nuovo blocco viene chiamata instrument() con il blocco come input. Questa funzione ha il compito di interpolare le istruzioni con il codice di instrumentazione (chiamate a funzioni del tool) e ritornare un nuovo blocco. Per il fatto che i blocchi hanno diversi punti d’uscita non ` assicurato che e tutte le istruzioni del blocco vengano eseguite, per questo il codice di instrumentazione va bufferizzato nel blocco d’uscita insieme ad esse e non eseguita direttamente in instrument(). 22
  • 22. fini() Stampa dei risultati e rilascio delle risorse. E’ possibile accede anche all’exit code del programma client.Il framework mette a disposizione anche altri strumenti per analizzare ilcodice in esecuzione, se si ha la possibilit` di ricompilare l’applicazione di pu` a ofare uso di client requests, per comunicare direttamente col tool tramitemacro inserite nel codice sorgente del client. Utili soprattutto per il debug-ging, il framework ne propone alcune e ogni tool ne implementa di proprie.Alcuni esempi:RUNNING_ON_VALGRIND Ritorna 1 se l’applicazione viene eseguita all’interno di Valgrind, 0 se su una vera CPU. Utile ad esempio per creare dei salti condizionali ed omettere alcune parti dell’esecuzione che rallen- terebbero troppo l’esecuzione simulata.VALGRIND_PRINTF(format, ...) Stampa un messaggio formattato sul file di log di Valgrind insieme ai messaggi del tool.VALGRIND_PRINTF_BACKTRACE(format, ...) Stampa lo stato corrente del- la stackVALGRIND_COUNT_ERRORS Ritorna il numero di errori rilevati finora dal toolE’ possibile implementare le proprie client request, modificando il codicedei tool ` quindi possibile far comunicare le proprie applicazioni con il eframework. Un’altra funzionalit` prevista ` quella di effettuare function wrapping a edi funzioni di libreria per analizzarne parametri passati e valori di ritorno.E’ presente un sistema di pattern per intercettare gruppi di funzioni connome simile (il nome a cui fare riferimento ` quello interno generato dal ecompilatore). La funzione di wrappingI_WRAP_SONAME_FNNAME_ZZ(libpthreadZdsoZd0, pthreadZucreateZAZa)intercetter` quindi le chiamate a tutte le funzioni che corrispondono al pat- atern pthread_create@* nella libreria libpthread.so.0, quindi di tuttele versione delle glibc (pthread_create@GLIBC_2.3, ...@GLIBC_2.4). Lefunzioni di wrapping possono poi chiamare l’originale con le macroVALGRIND_GET_ORIG_FN(fn);CALL_FN_W_WW(result, fn, x,y);3.5 Modifiche a CoregrindL’utilizzo di Valgrind per l’addestramento di HMM richiede la possibilit` adi eseguire la stessa applicazione client sotto il tool di instrumentazione 23
  • 23. diverse volte variando i parametri di input. E’ stata analizzata la strut-tura interna di Coregrind e sono state individuate le fasi principali del suoavvio per selezionare quelle candidate ad essere modificate per ottenere talefunzionalit`. a3.5.1 Wrapper internoLa prima soluzione sviluppata consiste in un wrapper scritto in POSIX C.E’ stata modificata le funzione main_process_cmd_line_options affinch` ericonoscesse l’opzione -wrap=<yes|no>. Se il parametro viene posto a yesil valore della stringa VG_(args_the_exename), che si riferisce all’eseguibileda lanciare, viene artificialmente posto al nome del wrapper. Valgrind loesegue passandogli gli argomenti da variare ed esso sostituisce il simbolo(arbitrariamente posto a con l’argomento variabile (nel caso di gzip conil nome del file da comprimere), quindi effettua una fork ed si sostituisce(execvep) con l’eseguibile client. Il processo padre chiamando wait attendeche il figlio completi l’esecuzione (per non sovrappore l’output dei due) erientra nel ciclo. Il vantaggio di questo sistema ` che ` completamente trasparente per il e eclient, esso non necessita di ricompilazione e la modifica rispetta l’architet-tura di Valgrind. Lo svantaggio principale ` che l’uso di fork/execve im- eplica la reinizializzazione del tool ad ogni esecuzione del programma client.Non ` quindi possibile mantenere un determinato stato del tool in memoria etra un’esecuzione e l’altra (in particolare ` la chiamata a execve che causa eil problema, Valgrind la gestisce semplicemente sostituendosi con un altroprocesso di Valgrind e non ricaricando un nuovo eseguibile).Il wrapper ` stato inserito nel sistema di build di Valgrind e pertanto auto- ematicamente compilato ed installato insieme al resto dei sorgenti.3.5.2 Thread wrapperLa seconda soluzione ` mirata a risolvere il problema sorto nella prima: emantenere uno stato tra le varie esecuzioni. Il sorgente del client andr` amodificato in modo tale da essere eseguito come funzione in un thread: ilwrapper gestisce delle struct contenti gli argomenti da passare ai diversithread e li esegue sequenzialmente, aspettando che uno finisca prima dilanciare il successivo. Questo viene fatto in quanto i thread condividendo lospazio di indirizzamento potrebbero entrare in conflitto su eventuali variabiliglobali. Per l’implementazione ` stata usata la libreria pthread ed ` stato con- e estatato che risolve i problemi della prima ma comporta un notevole svantag-gio obbligando a modificare e ricompilare il client, seppur minimamente. Lafunzione main del wrapper ` da compilare assieme al client. Il programma eclient dovr` essere modificato per accettare come parametro un puntatore a 24
  • 24. ad una struttura contentente argc, argv ed envp e dovr` terminare la sua aesecuzione chiamando pthread_exit anzich` exit. e3.5.3 Thread injectionPer trovare una soluzione che mantesse lo stato interno del tool tra le varieesecuzioni e che non richiedesse modifiche al client ` stata fatta un’analisi eapprofondita del sistema di thread e dello scheduler di coregrind, il frame-work sul quale si basano i tool di Valgrind. Seguendo il flow dell’esecuzionedi Valgrind sono stati effettuati diversi test prima per ripetere l’esecuzionedi un thread gi` concluso e poi per duplicarlo artificialmente, senza che esso aavesse chiamato clone. L’implementazione di questo motodo ` risultata possibile, ed ` stato e eindividuato nella funzione run_thread_for_a_while il punto ideale per ef-fettuare l’inserimento del thread artificiale, in quanto il pi` vicino all’ese- ucuzione delle istruzioni sulla cpu virtuale di Valgrind. Tale funzione (inscheduler.c) ` stata modificata affinch` anteponesse alla prima istruzione e edel client un chiamata a ML_(do_fork_clone). Con questa Valgrind duplicail thread che stava eseguendo in quel momento (che non condivider` per` a olo spazio di indirizzamento). Sono state effettuate con successo multipleesecuzioni con una singola inizializzazione del tool scelto (ma con multiplefinalizzazioni). Il passo successivo ` stato sostituirla con la chiamata ad una efunzione ancora pi` interna di coregrind, do_clone. u Questa modifica ha permesso di avere pi` thread eseguiti sequenzial- umente (Valgrind permette il multithreading ma esegue sempre un threadalla volta) con una sola inizializzazione e una sola finalizzazione del tool scel-to. Tuttavia non rispetta l’architettura originale del framework e potrebbeportare ad instabilit`, necessita quindi un maggiore approfondimento prima adi essere utilizzata con sicurezza.3.5.4 External stateSe il progetto prevede invece lo sviluppo di un nuovo tool da zero la soluzioneottimale si rivela quella di salvare lo stato del tool in un file copiandovile strutture di memoria come si trovano al momento della chiamata allafunzione fini() e ripristinarle all’esecuzione successiva. I tool di Valgrindnon sono per` linkati alla libreria c standard quindi ` necessario usare la o eversione reimplementata nel framework di tutte le funzioni di IO, definitenegli headers della directory include/ dei sorgenti. 25
  • 25. 26
  • 26. Capitolo 4SpecSpec 2006 si presenta come lo standard per la misura e la valutazione delleprestazioni di un sistema. L’utilizzo di un set di benchmark standard rendepossibile la comparazione dei risultati tra macchine, compilatori e opzionidi compilazione differenti tra loro.4.1 CPU2006Spec CPU2006 si concentra sulla performance del processore, sull’architet-tura della memoria e sulla capacit` del compilatore di produrre codice ot- atimizzato [10]. Altri fattori che spesso incidono sulle performance delle ap-plicazioni (networking, I/O) sono qui considerati trascurabili, in quanto isingoli benchmark sono stati sviluppati per ottenere il maggiore impattopossibile sulla cpu e sulla memoria rispetto al resto delle componenti delsistema. Spec si compone di due suite di benchmark principali: • CINT2006 • CFP2006La prima effettua un’analisi delle performance del sistema nelle operazionisu valori interi, la seconda nel caso di operazioni a virgola mobile (floatingpoint). Ognuna delle due suite di compone di diversi benchmark (12 perCINT2006, 17 per CFP2006).4.1.1 BenchmarkUn benchmark di SpecCPU2006 non ` altro che un’applicazione che effet- etua una serie di operazioni ben definite che hanno l’effetto di aumentare ilcarico di lavoro della cpu. Dei benchmark di SpecCPU2006 si misura speed,ovvero quanto rapidamente l’esecuzione viene completata, e throughput,quanti flussi di esecuzione si riescono a completare per unit` di tempo. a 27
  • 27. 4.1.2 Speed RatioLo standard di SpecCPU2006 definisce come ratio il rapporto tra il tempodi esecuzione di un benchmark sulla macchina e un tempo di riferimento de-terminato da Spec. E’ con questo valore che ` possibile mettere in relazione eil proprio risultato con risultati ottenuti su sistemi differenti.4.1.3 Throughput RatioVengono eseguite multiple (n) istanze del benchmark contemporaneamente.Il valore di throughput corrisponde al rapporto tra il tempo impiegato percompletare l’esecuzione di tutte le istanze ed n. Il throughput ratio ` equindi il rapporto tra il throughput della macchina e il valore di riferimentodi Spec.4.2 MisurazioniLa suite CINT2006 pu` essere eseguita in quattro modalit` differenti: o aSPECint2006 La media geometrica ottenuta su 12 ratio, normalizzati su 3 esecuzioni ognuno. Benchmark compilati in modalit` peak. a I 12 benchmark vengono eseguiti 3 volte, calcolandone il valore di speed ratio. Delle 3 esecuzioni di ogni benchmark viene presa la mediana e utilizzata per calcolare la media √ geometrica sui 12: G = r0 r1 · · · r11 . La media geometri- ca G viene utilizzata come risultato del test. I benchmark sono utilizzati in modalit` peak: per ognuno di essi possono a essere specificati flag di compilazione personalizzati cos` da ı ottimizzarne l’esecuzione.SPECint base2006 La media geometrica ottenuta su 12 ratio, normaliz- zati su 3 esecuzioni ognuno. Benchmark compilati in modalit` base. a Il valore di G viene calcolato allo stesso di SPECint2006, ma i benchmark vengono utilizzati in modalit` base: i flag a di compilazione devono essere uniformi tra tutti e 12. La modalit` base ` pi` restrittiva della modalit` peak. a e u aSPECint base2006 La media geometrica del valore di throughput ratio dell’esecuzione dei 12 benchmark in madalit` peak. aSPECint base2006 La media geometrica del valore di throughput ratio dell’esecuzione dei 12 benchmark in modalit` base. a Allo stesso modo di CINT2006, anche CFP2006 prevede quattro modal-it` di esecuzione differenti: a 28
  • 28. SPECfp2006 La media geometrica ottenuta su 17 ratio, normalizzati su 3 esecuzioni ognuno. Benchmark compilati in modalit` peak. aSPECfp base2006 La media geometrica ottenuta su 17 ratio, normalizzati su 3 esecuzioni ognuno. Benchmark compilati in modalit` base. aSPECfp rate2006 La media geometrica del valore di throughput ratio dell’esecuzione dei 17 benchmark in madalit` peak. aSPECfp rate base2006 La media geometrica del valore di throughput ratio dell’esecuzione dei 17 benchmark in madalit` base. a4.3 ConfigurazionePer eseguire SpecCPU2006 ` necessario scrivere un file di configurazione rel- eativo al proprio sistema. Le opzioni di configurazione si possono dividerein opzioni relative alla compilazione ed esecuzione dei singoli benchmark erelative all’output e ai report che genera la suite. E’ quindi necessario speci-ficare il path dei compilatori C, C++, Fortran, flag di compilazione comunia tutti i benchmark e opzionalmente anche flags personalizzati per ogni sin-golo benchmark (utilizzati per le misurazioni peak). Per poter pubblicareil report dell’esecuzione della suite ` necessario descrivere in modo partico- elareggiato hardware e software sulla quale ` stata eseguita: architettura, n◦ edi cpu, n ◦ di core per cpu, quantit` di memoria disponibile, motherboard, asistema operativo, versione dei compilatori... Si possono anche definire lepreferenze per quanto riguarda l’output dei risultati, se html, pdf, ascii.Un altro requisito affich` i proprio risultati siano marcati come reportable e` produrre il file flags.xml, dove va commentata ogni opzione passata alecompilatore.4.4 EsecuzionePer compilare ed eseguire i benchmark si utilizza runspec. Il procedi-mento da effettuare per testare se l’installazione e la configurazione del-la suite ` andata a buone file ` source ./shrc per settare le variabili e ed’ambiente, quindi runspec -config=example.cfg -fakereportable -Fflags-simple.xml -size=ref -tune=base int e nella directory resultverr` generato il report. Runspec prende come argomento uno o pi` bench- a umark da eseguire (int, fp, all). Le principali opzioni che regolano l’esecuzionedel tool sono:-action Definisce l’azione da compiere: build compila i benchmark, run compila(se necessario) ed esegue. clean rimuove file temporanei ed eseguibili compilati. 29
  • 29. -rate Se non presente il tool procede in modalit` speed run. Se presente a (argomento n) esegue n benchmark in parallelo, il test sar` quindi un a test di throughput-tune Settabile a base, peak o all. Default base.-reportable Per generare un report validoLe seguenti opzioni sono utili per effettuare dei test su un singolo benchmarko in modalit` particolari ma non permettono di generare un report valido: a-size Dimensioni del set di input, test, train o ref (reference). Reference ` e il set pi` ampio, con il quale l’esecuzione dura pi` a lungo u u-iterations Numero di volte che ogni benchmark va eseguito. Obbligato- riamente a 3 nel caso di reportable runs.4.5 BenchmarksSpecCPU2006 si prefigge di calcolare le prestazioni di un sistema simulandoun workload il pi` verosimile possibile, per questo molte dei benchmark sono udelle versioni adattate e modificate di applicazioni reali. Tali applicazionihanno in comune un’elevata intensit` computazionale: la maggior parte del atempo speso da esse ` dedicato ad operazioni di calcolo, con pochissimo eoverhead causato da input/output. Sono state apportate delle modifiche aisorgenti affich` i test eseguano la gran parte delle operazioni di IO in memo- eria e non su file, e affich` la memoria utilizzata rimanga inferiore ad 1GB per eevitare che il sistema debba effettuare swap verso il disco. Le applicazionisono state scelte basandosi anche su criteri di portabilit`, in quanto Spec- aCPU2006 pu` essere compilato su una moltitudine di architetture e sistemi ooperativi differenti.4.5.1 401.bzip2401.bzip2 ` la versione adattata a SpecCPU2006 del programma bzip2, il equale effettua compressione dati. 401.bzip2 si basa sulla versione 1.0.3di bzip2 di Julian Seward, con la differenza che 401.bzip2 non effettuaoperazioni di I/O se non nella lettura dei file da comprimere. Tutta lacompressione e la decompressione avviene quindi in memoria. I file utilizzati per la compressione e decompressione sono:chicken.jpg JPEG image data, 638Kliberty.jpg JPEG image data, 283Kinput.source POSIX tar archive, contenente il codice sorgente di perl- 5.8.5, 50M 30
  • 30. text.html HTML document text, 130Kinput.program Mach-O executable ppc, 7.7Minput.combined file composto da alcune parti molto comprimibili e altre meno, 52M. Si ` rivelato essere la combinazione dei file precedenti (le e immagini JPEG, il sorgente di perl e il file html)Ogni file viene compresso e decompresso 3 volte, a fattore crescente: 5, 7 e 9.I risultati della decompressione sono poi confrontati con il set di input pervalidare la buona riuscita del test. 401.bzip inizializza in memoria 3 bufferdi dimensione adeguata ad ospitare il file di input, lo stream compresso e lostream decompresso. Dopo aver caricato il file, le successive operazioni dilettura e scrittura sono effettuate tutte in memoria senza snaturare il codicedi bzip2 tramite le define:./bzlib.h:98: #define read(a,b,c) spec_read(a,b,c)./bzlib.h:104: #define write(a,b,c) spec_write(a,b,c)spec_read e spec_write non sono altro che wrapper di memcpy che gestis-cono gli EOF e che fanno corrispondere ai file descriptor i buffer preceden-temente allocati.4.5.2 445.gobmk445.gobmk ` una versione di GNU Go alla quale vengono presentate diverse eposizioni di gioco. Il gioco del Go ` considerato un problema di intelligen- eza artificiale che richiede uno sforzo computazionale elevato in quanto lecombinazioni possibili di pezzi sulla scacchiera (goban) nella partita sonomoltissime. I file di input utilizzati benchmark sono file di testo che descrivono diverseposizioni di gioco, l’output corrisponde nella mossa successiva da effettuare.4.5.3 458.sjeng458.sjeng ` una versione leggermente modificata di Sjeng 11.2, un program- ema che gioca a scacchi ed analizza e valuta posizioni di gioco. La versioneproposta da Spec rende le ricerche nell’albero delle varianti delle mosse deter-ministiche e quindi il workload del test sempre uguale. L’input di riferimentodel test ` composto da 9 differenti posizioni di gioco e dalla profondit` alla e aquale vanno analizzate da Sjeng.4.5.4 403.gcc403.gcc ` basato sulla versione 3.2 di GNU gcc, configurato per generare ecodice assembly x86-64 per un processore AMD Opteron con diverse flag di 31
  • 31. ottimizzazione abilitate. 403.gcc ` stato adattato da Spec alterando l’euris- etica nelle scelte di utilizzare funzioni inline affinch` il programma spendesse epi` tempo nell’analisi del codice sorgente e utilizzasse pi` memoria della u uversione standard. L’input ` dato da file sorgente per i quali deve essere egenerato l’assembly corrispondente.4.5.5 464.h264ref464.h264ref ` l’implementazione di Karsten S¨hring dello standard di com- e upressione video H.264/AVC. Le modifiche introdotte dal team di Spec facil-itano la portabilit` del codice ma sono state ridotte al minimo per garantire ache il test si avvicinasse il pi` possibile ad un caso d’uso reale di video en- ucoding. In particolare, ` stata rimossa la parte dei sorgenti riguardante il edecoder (il test effettua solo la compressione in h264, non la decompressione)ed ` stato soppresso l’output a file di log per minimizzare l’I/O. L’input ` e ecomposto da due video in formato raw ognuno dei quali viene compresso condue profili differenti (good compression e best compression).4.5.6 400.perlbench400.perlbench ` Perl v5.8.7 al quale sono state rimosse tutte le feature rel- eative ai singoli sistemi operativi. A questi sono stati aggiunti alcuni moduliesterni: SpamAssassin, MailTools, Digest-MD5, HTMLParser... I modulivengono utilizzati per la manipolazione di messaggi email trasformandoli inpagine html, calcolandone checksum md5 e rilevando con che probabilit` si atratta di spam.4.5.7 429.mcf429.mcf deriva da un software di scheduling del traffico utilizzato in ambitopubblico. 429.mcf genera un elevato carico sulla cpu eseguendo un algoritmoche implementa il metodo del simplesso su rete. Il codice del programmaoriginale ` stato modificato per ridurre il numero di cache miss e quindi incre- ementare l’impatto sulla cpu rispetto alla memoria. Questo ` stato ottenuto emodificando l’ordine degli elementi persenti nelle struct maggiormente uti-lizzate dal benchmark. L’input al benchmark consiste in un file di testocontente un insieme di percorsi da ottimizzare.4.5.8 462.libquantum462.libquantum simula un computer quantistico, eseguendo l’algoritmo difattorizzazione di Peter Shor. Il benchmark si aspetta in input un numeroe resituisce l’elenco dei suoi fattori. Su un computer quantistico l’algorit-mo trova i fattori con margine d’errore arbitrariamente piccolo in tempopolinomiale rispetto alla dimensione del numero in input. 32
  • 32. 4.5.9 456.hmmer456.hmmer utilizza algoritmo hmm per analizzare sequenze di dna. In inputil benchmark si aspetta un file database contente i modelli di riferimento euna sequenza nella quale effetuare la ricerca delle sequenze del database.4.5.10 471.omnetpp471.omnetpp simula una vasta rete ethernet basandosi sul sistema di simu-lazione discreto OMNeT++. OMNeT++ implementa completamente CS-MA/CD, i frame ethernet e IP per una simulazione del carico sulle reti. Ilbenchmark simula una rete contente circa 8000 computer e 900 tra switchese hubs suddivisi in diverse subnet. Il benchmark prende in input la topologiadi una rete e la configurazione degli host, e procede aumentando esponenzial-mente il volume di traffico simulando anche perdite di pacchetti. In ouputsono prodotte statistiche dettagliate sulla simulazione.4.5.11 473.astar473.astar deriva da una libreria di ricerca del percorso minimo utilizzataper le intelligenze artificiali nei videogames. In input accetta una mappa informato binario e il tipo di algoritmi da applicare per poi stampare le viepossibili per il raggiungimento della destinazione.4.5.12 483.xalancbmk483.xalancbmk deriva da Xalan-C++, un software che processa documentiXML trasformandoli secondo fogli di stile XSL. Implementa lo standardW3C delle XSL Transformations e di XML. Per renderlo un benchmark diSpec ` stato selezionato un test-set da processare di notevole dimensioni e(100MB) consistente in un file XML e un foglio di stile XSL da trasformarein HTML. 33
  • 33. 34
  • 34. Capitolo 5Analisi delle tracce diindirizziL’obiettivo dell’analisi consiste nel riuscire ad riconoscere a che program-ma corrisponde un processo sconosciuto in esecuzione utilizzando soltantola sequenza di indirizzi di memoria a cui accede. Si vuole testare l’efficaciadi apprendimento di hmm (modelli di Markov) e delle reti neurali nel ri-conoscere tratti caratteristici dello spettro delle tracce. Per poter utilizzaretali algoritmi di machine learning ` necessario trasformare la sequenza di in- edirizzi in una forma accettabile dai modelli, procedendo inizialmente con unacompressione della stessa: la traccia viene suddivisa in segmenti e di questiviene calcolata la trasformata del coseno. I primi parametri della traformatavengono presi come vettore rappresentante il segmento. Tali vettori vengonoquindi quantizzati tramite un algoritmo di k-means clustering per ottenereuna sequenza di chiavi appartenenti ad un alfabeto e quindi ad un dominiodiscreto. E’ con queste sequenze di chiavi che vengono addestrati i modellidi Markov e le reti neurali. Per la fase di analisi sono stati utilizzati come programmi i 12 benchmarkSPECint, i quali possono generare un numero ancora pi` elevato di possibili uprocessi in quanto ogni benchmark ha associati pi` possibili input, fino a 8 unel caso di gcc. Sono stati sviluppati due gruppi di tool per effettuare laclassificazione delle tracce, uno dei quali utilizza modelli di Markov e l’altroreti neurali addestrate tramite back-propagation. Per ognuno di essi sonopresenti tool di addestramento, tool di test e un vasto insieme di script perautomatizzare il processo di analisi. I tool sono stati sviluppati interamentein C mentre lo scripting ` stato effettuato in Ruby. Come piattaforma di esviluppo e test ` stato scelto un sistema Debian GNU/Linux. e 35
  • 35. 5.1 Addestramento hmmPartendo da una traccia di indirizzi generata dall’esecuzione di un bench-mark si vuole ottenere il modello hmm corrispondente a tale workload. E’stato sviluppato un tool in ansi C che effettua la parametrizzazione spettraledi un segmento della traccia e genera un nuovo modello hmm. Definita V la dimensione del vettore di indirizzi sui quali applicare laDCT, la trasformata discreta del coseno, e N il numero di vettori scelti perla finestra di questa fase dell’addestramento, sono individuati sulla tracciasul disco V N vettori. Di ognuno di questi viene calcolata la DCT e nevengono salvati i primi Cs elementi. Nel tool la DCT ` stata implementata ein C utilizzando come riferimento i paramentri di scala proposti in GNUOctave [11].Figura 5.1: I modelli hmm vengono addestrati utilizzando l’algoritmo diBaum-Welch su sequenze di centroidi Il procedimento descritto comporta una compressione dei dati disponi-bili, avendo ora in memoria N vettori di dimensione Cs si vuole discretizzarequesto insieme utilizzando un algoritmo di k-means clustering. L’imple-mentazione nel tool ` stata effettuata utilizzando come base algoritmica un esorgente ansi C sviluppato da Henrik Gruden, Gabriele Cutazzo, CristianoVanon, Enzo Mumolo. Tale sorgente ` stato esteso e adattato per poter allo- ecare tutte le strutture dati dinamicamente e gestire input e ouput bufferizzatiin memoria. L’algoritmo produce in output un insieme di Cn centroidi chefaranno parte del modello hmm e perci` devono essere memorizzati su disco. oPer i centroidi ` stato definito un formato di output binario. Ogni elemento edell’insieme di N vettori generati precedentemente pu` ora essere associato o 36
  • 36. ad un centroide: si procede quindi con una ulteriore compressione da Nvettori di Cs elementi a N interi appartenenti all’alfabeto di Cn centroidi. Ora che si ` ottenuta una sequenza di numeri interi ` possibile pro- e ecedere con l’addestramento di una hmm discreta di S stati: ` stata utiliz- ezata la libreria sviluppata da Tapas Kanungo [12] che applica l’algoritmodi BaumWelch per trovare la matrice degli stati della hmm. Tale libreria(open source) ` stata modificata per effettuare tutto il lavoro in memoria esenza richiedere input da file, affinch` tutto il procedimento dalla sequen- eza di indirizzi fino al completamento dell’addestramento potesse avveniresenza effettuare I/O su disco e affinch` fosse possibile definire la dimen- esione di tutte le strutture dati da linea di comando o comunque runtime enon a tempo di compilazione, per ottenere la massima flessibilit` nei test asuccessivi.5.2 Test hmmCon i file del modello hmm e dei centroidi ` possibile testare una traccia equalsiasi: il procedimento di parametrizzazione spettrale ` lo stesso ma i ecentroidi in questo caso non verranno calcolati ma caricati e verr` applicato al’algoritmo di Viterbi, il quale produce in output una probabilit`: la prob- aabilit` che la sequenza di indirizzi della traccia in ingresso appartenga a tale amodello hmm. Per mantere l’integrit` tra il tool di addestramento e quello adi test essi sono stati sviluppati come un unico sorgente che viene compilatoin modi differenti a seconda dei flag passati al compilatore da GNU make.Figura 5.2: Viene calcolata la probabilit` di appartenenza di una traccia ad aun modello con l’algoritmo di Viterbi utilizzando centroidi e modello hmm 37
  • 37. 5.3 Addestramento reti neuraliCome algoritmo di machine learning comparativo per i modelli di Markovnascosti sono state scelte le reti neurali [13]. Una rete neurale simula ilcomportamento dei neuroni biologici per ottenere un effetto di memoria ericonoscere pattern e similarit` tra gli input assegnati. Le reti utilizzate in aquesto caso si compongono di diversi neuroni organizzati in strati, con glistrati completamente connessi tra loro, ovvero ogni neurone di un determi-nato strato ` connesso con tutti i neuroni dello strato precedente i quali efungono da input. Ogni connessione tra i neuroni ha un peso. Ogni neuronecalcola il proprio valore di output effettuando la somma pesata di tutte leconnessioni in input ed applicando a questa somma una funzione di soglia, 1tipicamente la sigmoide f (x) = 1+e−x .Figura 5.3: Viene utilizzata la sequenza di centroidi come input per la rete Una rete di architettura cos` definita ` determinata quindi univocamente ı edai valori dei pesi. Sono stati utilizzati 3 strati: input layer, hidden layer, eoutput layer. E’ stato fatto uso di apprendimento supervisionato, ovvero adogni esempio per il quale si vuole addestrare la rete ` associato anche l’output edesiderato. Per tutto il codice relativo alle reti non si ` fatto affidamento ea librerie presenti in letteratura, ` stato implementato ex-novo utilizzando el’algoritmo di back-propagation dell’errore per effettuare l’aggiornamentodei pesi. Per poter effettuare una comparazione tra il modello di apprendimentohmm e le reti neurali nel caso della classificazione di tracce di indirizzi ` stato eutilizzato lo stesso procedimento di parametrizzazione spettrale. Ottenutala sequenza di N interi questi sono riportati in forma binaria su log2 Cn bitognuno, cos` che ogni bit 0, 1 diventi un input per il primo strato di neuroni. ı 38
  • 38. Tali input vengono utilizzati in gruppi di mlog2 Cn come esempi di un set diapprendimento per la rete reurale. Il set di apprendimento viene generatosovrapponendo un esempio di mlog2 Cn input col successivo in diversi modiper addestrare la rete alla sequenza di simboli.5.4 Test reti neuraliPer il test di una rete viene selezionato un punto casuale della traccia dalquale far partire la lettura degli indirizzi, ottenuto un set di N interi quantiz-zando i vettori risultato della dct questi vengono riportati in forma binariaallo stesso modo della fase di addestramento e mappati sugli input della rete.L’output della rete ` dato da un valore reale compreso tra [0, 1]. e5.5 Analisi offlineL’analisi offline prevede di analizzare una traccia di indirizzi pre-generataleggendola dal disco. Per generare le tracce ` stata sviluppata un’estensione edi Valgrind, tracebin, che genera le tracce in formato binario. Il formatodel file ` definito dalle chiamate a VG_(write) presenti in tracebin: eVG_(write)(fd_bin,&addr,sizeof(Addr));VG_(write)(fd_bin,&ss,sizeof(UShort));VG_(write)(fd_bin,&op,sizeof(Char));VG_(write)(fd_bin,&padding,sizeof(Char));Sono registrati indirizzo, dimensione in byte e modalit` di accesso. L’ottavo abyte ` di padding ed ` sempre 0xFF. e e Sono state quindi generate due tracce per ogni benchmark con diversiinput scelti tra quelli previsti da SPECint. Per la prima fase di analisi sonostati utilizzati 4 diversi benchmark, 2 tracce per ognuno di essi variandonel’input tra la prima e la seconda esecuzione. I benchmark utilizzati conrelativi input e dimensione delle tracce sono:400.perlbench checkspam (37GB), diffmail (40GB)401.bzip2 chicken.jpg (55GB), text.html (45GB)403.gcc 166.i (58GB), 200.i (51GB)445.gobmk nntgs.tst (31GB), score2.tst (32GB)5.5.1 HmmSono stati sviluppati due programmi che effettuano addestramento e testdelle tracce. Il primo produce come output due file caratterizzanti il modelloaddestrato (relativi a centroidi ed hmm), il secondo applica l’algoritmo di 39
  • 39. Viterbi e stampa un valore floating point corrispondente alla probabilit` che ala traccia processata corrisponda al modello addestrato. I due programmisono configurabili tramite le seguenti opzioni:./train [options] <tracefile>./test [options] -C [centroids file] -H [hmm file] <tracefile>-w <int> numero di blocchi di indirizzi da processare, def 1000-d <int> numero di indirizzi per blocco, default 1024-v <int> dimensione dei vettori da quantizzare, default 16-c <int> numero di centroidi, default 64-n <int> numero di stati della hmm, default 12-s <int> offset dal quale iniziare l’analisi, default 0-D <string> output directory, default "/tmp"5.5.2 Reti neuraliPer le reti neurali sono stati sviluppati 3 programmi: un programma segueil processo di parametrizzazione precedentemente spiegato per generare undue training set: uno generato dalla traccia di riferimento e un set generatoda altre tracce scelte casualmente. Un secondo programma effettua l’ap-prendimento addestrando la rete per riconoscere con output vicino a 1.0 iltraining set generato dalla traccia di riferimento e con output vicino a 0il training set generato dalle altre tracce. Un programma ancora diversoeffettua il test prendendo un segmento da una traccia definita da linea dicomando. Separando in diversi tool il lavoro ` stato possibile parallelizzare gli step edei procedimenti ed effettuare addestramenti di reti con diversi parametri apartire dallo stesso training set.5.6 Analisi con ValgrindL’analisi offline comporta uno svantaggio ineludibile, l’accesso al disco: perprocessare diversi GB di traccia occorre molto tempo. Effettuare l’analisi di-rettamente all’interno di Valgrind mentre il programma ` in esecuzione per- emetterebbe di evitare di dover generare, memorizzare e leggere i file traccia.E’ stato sviluppato quindi un tool per Valgrind che applica la parametriz-zazione spettrale ed esegue apprendimento e test di hmm utilizzando diret-tamente gli indirizzi di memoria via via che vengono generati dai benchmark.A tale tool ` stato dato il nome di tracehmm ed ` stato inserito nel sistema e edi compilazione di Valgrind assieme agli altri tool della distribuzione. Il porting all’interno del framework dei tool sviluppati per l’analisi of-fline non pu` essere effettuato direttamente in quanto sia i tool sia coregrind onon possono utilizzare alcuna libreria utilizzata anche dal client, nemmeno 40
  • 40. glibc. Per quanto riguarda la libreria standard ` stato necessario riscri- evere tutte le chiamate di scrittura/lettura da file e di allocazione e copiadella memoria affinch` utilizzassero il sottinsieme di funzioni libc reimple- ementate all’interno del framework appositamente per questo scopo. Inoltrenon essendo possibile utilizzare nemmeno la libreria matematica sono stateselezionate le funzioni necessarie per l’analisi (cos,sqrt,log) ed inserite inmodo indipendente dalla libm insieme ai sorgenti del tool. Per verificare chel’importazione fosse stata effettuata correttamente ` stata anche effettuata euna comparazione dei risultati con quelli ottenuti eseguendo le istruzioniSSE2 non portabili fcos,fsqrt,fyl2x come assembly inline. Anche l’ar-chitettura dei tool precedenti ` stata cambiata per rispettare la struttura einterna di Valgrind, che non offre l’accesso ad un flusso di istruzioni linearema prevede che venga inserito codice di instrumentazione in tutti i blocchi diistruzioni tradotti, i quali verranno eseguiti solo se l’esecuzione raggiunger` aquel particolare punto.5.6.1 TracehmmIl tool sviluppato presenta un’interfaccia completamente configurabile daopzioni da linea di comando:usage: valgrind --tool=tracehmm [options] prog-and-args --new=<model.hmm> train a new hmm model --resume=<model.hmm> resume training --test=<model.hmm> test hmm model --centroids=<model.ct> centroids file --skip=<int> memory blocks to skip --window=<int> window size --verbose=yes|no verbose [yes] --vverbose=yes|no very verbose [no] --ct-n=<int> num of centroids --st-n=<int> num of statusesCon esso ` possibile effettuare sia l’apprendimento di un nuovo modello sia ecaricare un modello precedentemente generato e riprendere l’addestramen-to. Questa seconda funzionalit` si rivela utile per addestrare un modello agenerico di un benchmark indipendente dall’input assegnatogli inizialmente,effettuando diversi cicli di addestramento variando l’input assegnato. Durante l’esecuzione di un programma ogni volta che si entra in un nuovoblocco di istruzioni questo viene tradotto in VEX IR con il quale coregrindchiama la funzione th_instrument del tool. Questa funzione ha il com-pito di manipolare il blocco di istruzioni aggiungendo il proprio codice diinstrumentazione nella forma tipicamente di chiamate a funzioni C e di ri-tornare un nuovo blocco. In questa fase sarebbe anche possibile rimuovereo modificare istruzioni esistenti. 41
  • 41. Figura 5.4: Struttura di tracehmm Tracehmm riconosce le istruzioni che effettuano accessi in memoria eprepone ad ognuna di esse nel blocco di istruzioni che ritorner` a coregrind auna chiamata alla funzione th_addresshandler con il meta-indirizzo del-l’istruzione interessata come parametro.Non ` possibile registrare gli indirizzi in questo momento dell’instrumen- etazione in quanto non sono ancora indirizzi ma meta-indirizzi, questo perch` eil blocco che ` stato analizzato n` ha un flusso di esecuzione lineare (single- e eentry, multiple-exit) n` ` assicurato che venga eseguito soltanto una volta: eeValgrind effettua il caching della traduzione dei blocchi. I meta-indirizzicontengono quindi informazioni su come ottenere l’indirizzo dell’accesso inmemoria e non l’indirizzo stesso: quando il blocco verr` eseguito coregrind atrover` le chiamate a th_addresshandler, generer` l’indirizzo reale e la a afunzione cos` chiamata potr` aggiungere l’indirizzo al suo buffer. Per le in- ı astruction fetch ` pi` semplice in quanto basta passare a th_addresshandler e uil valore del program counter.th_addresshandler per prima cosa controlla per` di aver rispettato l’offset oindicato dall’opzione -skip=offset: i primi of f set · buf f ersize indirizzivengono scartati come richiesto dall’utente. Quindi un vettore di indirizziviene gradualmente riempito fino a raggiungere la dimensione stabilita perquale iniziare l’analisi: effettuare la DCT del vettore e salvarne i risultati.Questo viene ripetuto per un numero di volte definito da -window perch` poi e 42
  • 42. venga chiamata th_action_NORETURN() (` stata rispettata la convenzione einterna a Valgrind per i nomi delle funzioni) e l’analisi prosegua allo stessomodo dei tool offline. 43
  • 43. 44
  • 44. Capitolo 6Risultati sperimentaliIl procedimento di analisi delle tracce ` stato suddiviso in due parti: analisi eoffline e analisi in Valgrind. Nel primo caso ` stato analizzato un insieme edi 4 benchmark, nel secondo ` stato possibile effettuare prove sull’insieme ecompleto dei 12 benchmark di SPECint. I 4 benchmark del primo insiemedi test sono stati scelti in base ad un criterio di disponibilit` di input: gcc, abzip2, gobmk e perlbench presentano ognuno 4 o pi` file sui quali ef- ufettuare l’addestramento rispetto ad altri benchmark i quali offrono menopossibilit` di scelta. a Figura 6.1: Processo di classificazione di una traccia sui modelli Le modalit` di test utilizzate sono due, alle quali ` stato dato il nome di a everifica e classificazione. La modalit` di verifica consiste nell’addestrare acon un benchmark B un modello hmm e eseguire su questo modello testdi affinit` con B e poi con tutti gli altri benchmark. Per ognuno viene aquindi confrontata la probabilit` che il modello corrisponda alla traccia con ala probabilit` generata da B. La percentuale di casi per i quali la probabilit` a adel benchmark effettivamente corrispondente alla traccia ` maggiore rispetto eagli altri indica la percentuale successo del test di verifica. Il test di classificazione invece prevede di addestrare un insieme di modellicompleto, uno per ogni benchmark, e con questi effettuare il test di unbenchmark B: se il modello che ` stato addestrato con B risponde con un e 45
  • 45. probabilit` pi` alta degli altri il test ha avuto successo. In particolare per a uogni coppia formata da traccia e benchmark che dichiara di essere deve essereeffettuata la scelta tra: • H0 ≡ il processo corrisponde al benchmark dichiarato • H1 ≡ il processo non corrispondePer decidere tra le due ipotesi viene effettuato un test di affinit` ovvero acalcolata le probabilit` P di appartenenza della sequenza: a P (H0 ) • P (H1 ) > Θ allora l’ipotesi viene accettata P (H0 ) • P (H1 ) < Θ viene rifiutata.Come descritto in dettaglio a pag. 51 si vuole trovare un valore di Θ chemassimizzi numero di riconoscimento corretti, ovvero che limiti al massimoi casi per cui si ottiene un falso positivo o un falso negativo. Tali eventisi verificano quando un modello presenta affinit` maggiore con il benchmark aeseguito rispetto a tutti gli altri pur non essendo quello realmente corrispon-dente (falso positivo) o quando un processo dichiara di appartenere ad unbenchmark che in realt` non gli corrisponde e questo non viene riconosciuto a(falso negativo).6.1 Risultati test offlineI limiti imposti dalla metodologia di analisi offline hanno permesso di effet-tuare test su porzioni di tracce di dimensioni limitate, in particolare ` stato escelto di effettuare solamente test di verifica in quanto pi` rapido del test di uclassificazione. Il processo di riconoscimento utilizzato in questa fase prevededi addestrare un modello hmm utilizzando una sola traccia e testarlo contutte le 8 tracce del set di 4 benchmark scelto. Se il test di Viterbi produceuna probabilit` maggiore per le due tracce appartenenti al benchmark as- asociato al modello allora il test ha avuto successo. Per quanto riguarda lereti neurali un valore prossimo a 1 dato dal neurone di output significa chela traccia ` stata riconosciuta. e6.1.1 Test di verifica hmmPer trovare i valori ottimali dei parametri di addestramento ` stato svilup- epato uno script che effettua test variando il numero di stati, di centroidi,di blocchi di indirizzi e la dimensione dei vettori per addestrare e testare imodelli. Parametri ottimali per le 4 tracce prese in esame in questa fase sonostati trovati in 64 centroidi e 12 stati (fig 6.2), con i quali ` stato possibile ericonoscere tutte le 8 tracce nel caso di segmenti di addestramento e testdi dimensione contenuta. Con tali parametri le tracce di bzip rispondono 46
  • 46. con valori molto pi` elevati rispetto alle altre quando testate su un modello uhmm addestrato con bzip, e lo stesso per gcc, gobmk e perlbench. Figura 6.2: precisione nel riconoscimento al variare di stati e centroidi Nel grafico in fig 6.3 ` rappresentata l’affinit` (in ordinata) di ognuna e adelle 8 tracce (in ascissa) rispetto ad un modello di hmm addestrato a ri-conoscere un determinato benchmark (in legenda). Le tracce sono disposte acoppie, la prima coppia a sinistra corrisponde ai benchmark 400.perl.diffmaile 400.perl.checkspam. I valori per i primi due punti rispetto all’asse delleascisse sono maggiori rispetto a tutti gli altri, la traccia ` stata quindi ri- econosciuta come proventiente dal benchmark 400.perl. Le stesse consid-erazioni si possono fare per gli altri benchmark: 401.bzip2 (punti 3 e 4),403.gcc (punti 5 e 6) e 445.gobmk (ultimi due punti). Comparando i singoli risultati tra loro si pu` notare che alcuni bench- omark siano pi` facili da riconoscere rispetto ad altri. I risultati relativi a u401.bzip2 presentano molto scarto tra quelli ottenuti nei test con il loro mod-ello e quelli di altri benchmark. Inoltre addestramenti di modelli differentima relativi allo stesso benchmark portano a risultati compatibili tra loro neitest, indicando una buona generalizzazione degli stessi.6.1.2 Test di verifica reti neuraliLo stesso procedimento ` stato utilizzato per provare l’efficacia delle reti eneurali in questo contesto. Effettuando un singolo test delle 8 tracce su 4reti non si ottengono risultati validi, ma siccome la procedura di calcolo del-l’output di una rete neurale ` molto pi` rapida dell’algoritmo di Viterbi per e u 47
  • 47. Figura 6.3: test offline hmm su 8 tracceuna hmm, per ogni test traccia/modello sono stati calcolati numerosi out-put della rete prendendo come punto d’ingresso diversi punti della traccia.Escludendo i valori massimi e minimi di questo set di risultati ` possibile enotare un trend nel riconoscimento delle tracce. Nel grafico in fig 6.4, rela-tivo ad una rete addestrata con perlbench, si pu` notare come la sequenza odi test relativi alle due tracce generate con perlbench sia sempre superioreai test effettuati con le tracce degli altri benchmark. Estendendo questo processo a tutti e 4 i benchmark non si ottengonoper` gli stessi risultati(fig 6.5): gcc ` risultato non riconoscibile e anche o ealtre tracce non sono state riconoscibili al 100%. Con i risultati ottenuti si ricava che l’apprendimento tramite hmm dis-crete risulta pi` efficace rispetto alle reti neurali nel caso di tracce parametriz- uzate spettralmente. Per fase analisi successiva si ` scelto quindi di effettuare etest pi` estesi utilizzando soltanto hmm. u6.2 Analisi su ValgrindLo sviluppo del tool tracehmm ha permesso di effettuare una serie di testmolto pi` estesa variando i training set mantenendo tempi di esecuzione uragionevoli. Sono stati effettuati nuovamente i test di verifica descritti inprecedenza seguiti da estesi test di classificazione. 48
  • 48. Figura 6.4: serie di test di riconoscimento di perlbench utilizzando retineurali Figura 6.5: precisione nel riconoscimento di 8 tracce con le reti neurali 49
  • 49. 6.2.1 Test di verificaPrima di utilizzare tutti i 12 benchmark di Spec sono stati effettuati nuova-mente i test di verifica su 4 tracce utilizzando per` pi` input a disposizione, o uper un totale di 16 tracce provenienti dagli stessi 4 benchmark, ottenendogli stessi risultati dei test offline. In fig. 6.6 si possono vedere i risultati dellostesso test di verifica effettuato per` sull’insieme completo dei 12 benchmark, oottenendo una percentuale di riconoscimento media dell’80%. Figura 6.6: Risultati test di verifica su 12 benchmark, 30 tracce6.2.2 Test di classificazionePer la fase di apprendimento sono stati utilizzati tutti i 12 benchmark diSpec INT2006, di ogni benchmark ` stato calcolato un modello hmm utiliz- ezando i valori ottimali di centroidi e di stati ottenuti nei test offline effettuatiprecedentemente (64 centroidi, 12 stati). Ogni modello ` stato addestrato eeseguendo il benchmark pi` di una volta variandone l’input, al fine di otten- uerne un modello il pi` generalizzato possibile. Sono stati sperimentati tre udiversi modi di apprendimento dei modelli, utilizzando parti differenti dellatraccia in ingresso.standard Definita W la dimensione della finestra di indirizzi da utilizzare per il calcolo dei centroidi e per un primo apprendimento, S il numero di indirizzi da scartare prima di iniziare l’apprendimento, di ogni in- put vengono utilizzati per l’addestramento N finestre di indirizzi W a partire da S + W k. Fig: 6.7 50
  • 50. dimensioni ridotte Definita W la dimensione della finestra di indirizzi da utilizzare per il calcolo dei centroidi e per un primo apprendimento, S il numero di indirizzi da scartare prima di iniziare l’apprendimento, di ogni input vengono utilizzati per l’addestramento N finestre di indirizzi W/2 a partire da S + (W/2)k. Fig: 6.8sovrapposizione Definita W la dimensione della finestra di indirizzi da utilizzare per il calcolo dei centroidi e per un primo apprendimento, S il numero di indirizzi da scartare prima di iniziare l’apprendimento, di ogni input vengono utilizzati per l’addestramento N finestre di indirizzi W a partire da S + (W/R)k. Fig: 6.9 I test vengono effettuati applicando l’algoritmo di Viterbi ad un bench-mark per ogni modello. Il valore di output (probabilit`) del test di Viterbi adel modello corrispondente al benchmark eseguito viene preso come valore diriferimento. I valori corrispondenti agli altri modelli vengono confrontati conquesto, se presentano affinit` maggiore con il benchmark eseguito vengono acontati come falsi positivi. Per trovare i falsi negativi viene eseguito un benchmark ma preso comemodello di riferimento uno corrispondente ad una traccia diversa. In questocaso se il modello presenta pi` affinit` rispetto a tutti gli altri modelli si ` u a ein presenza di un falso negativo. L’affinit` di un’esecuzione con quella di ariferimento si calcola come il rapporto tra la probabilit` del modello preso ain considerazione moltiplicata per un valore θ rispetto a quella del modellodi riferimento. Al variare di θ quindi un determinato benchmark produrr` api` o meno falsi positivi/negativi. u Per ogni modello di addestramento preso in considerazione sono statieseguiti i benchmark con diversi input in ingresso e calcolata poi la per-centuale di errore al variare di θ. Con i parametri utilizzati si riesce quindiad ottenere una precisione media nella classificazione delle tracce di circa80% come presente in Fig. 6.12, ovvero dove le linee di falsi positivi e falsinegativi si intersecano. Al crescere dell’insieme di test il modello di apprendimento migliore cam-bia, e sono necessari insiemi di test pi` grandi per un corretto riconosci- umento delle tracce. Sono stati effettuati test su tutti i 12 benchmark diSpecCPU2006 e calcolato i valori ottimale di θ. In Fig 6.14 si ottengono irisultati migliori, assestando intorno al 25% l’errore di classificazione delletracce. Utilizzando il set completo di benchmark di SPECint la precisione deirisultati diminuisce ma si assesta comunque tra 70% e 80% utilizzando unametodologia di apprendimento adeguata. 51
  • 51. Figura 6.7: In chiaro a sinistra la parte di traccia utilizzata per definire icentroidi. A destra le parti utilizzate per la prosecuzione dell’addestramentostandardFigura 6.8: In chiaro a sinistra la parte di traccia utilizzata per definire icentroidi. A destra le parti utilizzate per la prosecuzione dell’addestramentoa finestre di dimensioni ridotteFigura 6.9: In chiaro a sinistra la parte di traccia utilizzata per definire icentroidi. A destra le parti utilizzate per la prosecuzione dell’addestramentocon sovrapposizione 52
  • 52. Figura 6.10: Risultati con addestramento del tipo standard con 4 bench-mark, 4 input per benchmark (16 tracce). L’addestramento standardprevede di utilizzare lo stesso numero di segmenti di traccia per il calcolodei centroidi e per la prosecuzione dell’addestramento. 53
  • 53. Figura 6.11: Risultati con addestramento del tipo dimensioni ridottecon 4 benchmark, 4 input per benchmark (16 tracce). Tale tipo di addestra-mento prevede di utilizzare un numero di segmenti di traccia molto ampioper calcolare i centroidi nel modo pi` accurato possibile e un numero di usegmenti minore per la prosecuzione dell’addestramento. 54
  • 54. Figura 6.12: Risultati con addestramento del tipo sovrapposizione con 4benchmark, 4 input per benchmark (16 tracce). Tale tipo di addestramentoprevede di utilizzare un segmenti di traccia parzialmente sovrapposti perl’addestramento, come in fig. 6.9. 55
  • 55. Figura 6.13: Risultati con addestramento del tipo standard con 12 bench-mark, 30 tracce totali. L’addestramento standard prevede di utilizzare lostesso numero di segmenti di traccia per il calcolo dei centroidi e per laprosecuzione dell’addestramento. 56
  • 56. Figura 6.14: Risultati con addestramento del tipo dimensioni ridottecon 12 benchmark, 30 tracce totali. Tale tipo di addestramento prevededi utilizzare un numero di segmenti di traccia molto ampio per calcolare icentroidi nel modo pi` accurato possibile e un numero di segmenti minore uper la prosecuzione dell’addestramento. 57
  • 57. Figura 6.15: Risultati con addestramento del tipo sovrapposizione con12 benchmark, 30 tracce totali. Tale tipo di addestramento prevede diutilizzare un segmenti di traccia parzialmente sovrapposti, come in fig. 6.9. 58
  • 58. Per migliorare i risultati ottenuti si potrebbe effettuare una selezionedi benchmark, accorpandone alcuni che presentano affinit` molto elevata, o arimuovere alcuni input che non risultano facilmente associabili agli altri in-put del benchmark. Per effettuare queste considerazioni sono state prodottematrici di confusione per ogni gruppo di modelli hmm come la seguente: quantum hmmer xalanc omnet sjeng astar h264 bzip perl mcf gcc go omnet 4 3 3 2 5 4 4 2 1 1 1 sjeng 4 4 3 6 5 6 6 3 6 6 6 xalanc 3 4 0 2 3 4 4 2 1 0 1 astar 3 3 0 2 5 3 4 2 2 1 1 h264 2 6 2 2 4 6 5 5 0 4 1 hmmer 5 5 3 5 4 5 5 4 3 4 3 mcf 4 6 4 3 6 5 6 5 6 6 5 perl 4 6 4 4 5 5 6 5 4 4 4 quantum 2 3 2 2 5 4 5 5 5 5 6 gcc 1 6 1 2 0 3 6 4 5 3 4 go 1 6 0 1 4 4 6 4 5 3 1 bzip 1 6 1 1 1 3 5 4 6 4 1Numero di volte che un test viene riconosciuto erroneamente comeappartenente ad un altro modello, 30 test totaliOgni numero corrispondente ad una coppia di benchmark indica il numerodi volte che tali tracce sono state erroneamente riconosciute l’una con l’altranel test effettuato. Ipotizzando di poter dividere i programmi di riferimentoin gruppi molto diversificati tra loro, sono state prese per effettuare unaprova le 4 tracce meno correlate e di esse ` stato calcolato l’errore al variare edi θ, raggiungendo una precisione superiore al 95%, Fig 6.16. Inoltre se siconsidera un certo margine d’errore nel rapporto tra la probabilit` di Viterbi adel modello e quello della traccia sconosciuta e non si pone la soglia a 1.0ma a 1.00 ± 0.05 o 1.00 ± 0.10 a seconda che si vogliano minimizzare di pi` ui falsi negativi/positivi, i risultati migliorano anche mantenendo un insiemedi benchmark ampio, in Fig. 6.17 i risultati relativi alla classificazione 12benchmark utilizzando un valore di soglia di 1.00 ± 0.05. 59
  • 59. Figura 6.16: Risultati del test di classificazione effettuato su un set ad-destrato in modo standard utilizzando i 4 benchmark con correlazione pi` ubassa: astar, xalanc, go e bzip nel caso della matrice a pag. 59. L’ad-destramento standard prevede di utilizzare lo stesso numero di segmenti ditraccia per il calcolo dei centroidi e per la prosecuzione dell’addestramento. 60
  • 60. Figura 6.17: Risultati del test di classificazione effettuato su un set ad-destrato in modo standard utilizzando una soglia di 1.00 ± 0.05 per falsipositivi e negativi. L’addestramento standard prevede di utilizzare lo stessonumero di segmenti di traccia per il calcolo dei centroidi e per la prosecuzionedell’addestramento. 61
  • 61. 62
  • 62. Capitolo 7ApplicazioniDi un processo in esecuzione ` in genere possibile conoscere il nome del- el’eseguibile dal quale ` stato caricato in memoria analizzando la lista dei eprocessi. Il nome riportato non d` la certezza per` che l’eseguibile caricato a osia realmente quello specificato, in quanto su molti sistemi ` possibile cam- ebiare runtime il nome del processo. Sarebbe poco efficace anche controllareche l’eseguibile in memoria corrisponda a quello sul disco in quanto questonon garantirebbe che l’esecuzione del programma avvenga principalmente inquel blocco di istruzioni. Inoltre gli strumenti comuni di risconoscimento di un processo fornisconoinformazioni dettagliate sulle risorse attualmente utilizzate dal programmama non permettono di sapere a breve o lungo termine che risorse richieder` ail processo. La capacit` di riconoscere un processo in esecuzione dal work- aload generato si pu` rivelare quindi utile in caso si voglia gestire in modo oparticolare l’esecuzione di certe applicazioni sul sistema.7.1 Monitoraggio e sicurezzaE’ possibile utilizzare il riconoscimento di processi tramite hmm per mon-itorare le applicazioni in esecuzione su di un server/cluster: addestrandouna serie di modelli hmm con le applicazioni che si vogliono riconoscere ` epossibile controllare che programmi sono effettivamente in esecuzione sul-la macchina. Sono previsti due scenari possibili, in caso sia pi` indicato uutilizzare una whitelist o una blacklist.7.1.1 WhitelistNel caso di applicazioni mission critical si pu` volere essere sicuri che i oprocessi in esecuzione siano effettivamente appartenenti all’applicazione instato di produzione e non ci siano dei thread malevoli mascherati da threaddell’applicazione in grado di accedere a dati riservati: stilando una whitelist 63
  • 63. dei servizi offerti dal server ` possibile allertare un ammistratore di sistema ein caso i risultati dei test di hmm scendessero sotto una certa soglia. In caso di provider offrenti sulle proprie macchine servizi limitati soload alcune applicazioni, come server web limitati all’esecuzione di script ogestione di email, si pu` riconoscere l’installazione di software non permessi oquando l’esecuzione di questi differisse da quelli in whitelist.7.1.2 BlacklistAllo scenario di un provider di servizi precedente pu` essere applicata anche ouna soluzione facente uso di blacklist: si possono riconoscere programmi es-plicitamente non permessi e bloccarne l’esecuzione. Tale soluzione pu` essere oapplicata anche in ambiti differenti, ad esempio nel caso di contratti d’usoper i quali ` stato firmato un End User License Agreement con condizioni eparticolari, il gestore pu` essere interessato ad inibire l’uso di particolari osoftware.7.2 Allocazione di risorseMetodologie di riconoscimento del workload possono rivelarsi fondamentaliper una distribuzione efficace delle risorse hardware disponibili: sono pre-visti due scenari di applicazione, nel caso di sistemi operativi dove si vuoleottimizzare l’interazione tra processi nelle richieste di risorse e nel caso di sis-temi virtualizzati dove l’obiettivo ` incrementare le performance delle singole evirtual machine.7.2.1 Sistemi operativiNel caso di sistemi operativi sottoposti a carichi elevati pu` rivelarsi fon- odamentale riuscire a predirre il prima possibile la quantit` di memoria che arichieder` un processo durante la sua esecuzione: utilizzando un procedi- amento di riconoscimento hmm sulla prima parte di indirizzi generata dalprocesso si pu` classificare il workload ed allocare risorse al processo di con- oseguenza. Tali sistemi potrebbero cos` diminuire le latenze delle richieste di ıallocazione dinamica di memoria.7.2.2 Ambienti di virtualizzazioneIn ambienti di virtualizzazione inoltre potrebbe essere utile conoscere lanatura di un processo in esecuzione su una determinata virtual machineper modificare la distribuzione di risorse tra le varie macchine virtuali: adesempio in caso di processi richiedenti ampi blocchi di memoria le risorsehardware potrebbe essere ripartite in modo efficace riconoscendo per tempoquali virtual machine avranno un burst nelle richieste di allocazione e quindi 64
  • 64. liberare blocchi di dati cached di conseguenza. Tale software di virtualiz-zazione potrebbe cos` massimizzare la quantit` di memoria offerta ai singoli ı asistemi client.7.3 ImplementazioneI procedimenti di estrazione delle tracce finora utilizzati sono adatti allafase di ricerca dei parametri ottimali e di addestramento dei modelli dautilizzare, ma per applicare in un contesto pratico gli algoritmi sviluppati ` enecessario trovare metodi differenti di generazione delle tracce. Con Valgrind` stato possibile effettuare analisi in modo molto pi` rapido in quanto none upi` necessario salvare la traccia, ma la sua architettura gli impedisce di uinstrumentare un processo gi` in esecuzione. a Prendendo in esame un sistema Linux x86 sono qui di seguito pro-poste modalit` in user space, in kernel space e nel caso di sistemi avirtualizzati.7.3.1 User spaceFigura 7.1: Un programma in user space ferma il processo e ne permettel’esecuzione un’istruzione alla volta monitorando gli indirizzi a cui accede Per ottenere una traccia di indirizzi in user space ` necessario operare ecome un debugger: fermare l’esecuzione di un processo, leggere il programcounter e analizzare l’istruzione che sta per essere eseguita. In Linux ` epossibile utilizzare la system call ptrace per ottenere accesso allo spazio diindirizzi di un altro processo ed accedere ai suoi registri. Un tool pu` quindi oessere sviluppato per attaccarsi ad un processo in esecuzione fermandolo,leggere EIP e salvare l’indirizzo come accesso in memoria di tipo instructionfetch, effettuare il parsing dell’istruzione puntata e aggiungere alla traccia gliindirizzi ai quali accede. Intel ha reso disponibile pintool [14] che permettedi effettuare tali operazioni su piattaforme x86 operando interamente in userspace. 65
  • 65. 7.3.2 Kernel spaceFigura 7.2: Si simula un page fault ad ogni riferimento in memoria delprocesso per ottenere l’indirizzo direttamente nel kernel Il kernel Linux non effettua via software la traduzione di pagine virtuali inpagine fisiche ma utilizza l’hardware della memory management unit delprocessore (x86). Pertanto non ` possibile accedere alla sequenza di indirizzi evirtuali senza intervenire sulla logica della MMU. In Linux ogni processo hauna sua page table, un metodo possibile di intervento ` quello modificare la epage table del processo del quale interessano gli indirizzi perch` la pagine erisultino tutte come non presenti: ogni accesso generer` un page fault, il akernel ottiene cos` l’indirizzo che ha generato il page fault nel registro cr2 ıe pu` memorizzarlo. I flags delle varie pagine vanno manipolati perch` il o ebit di presenza della pagina sia sempre a zero cos` da generare gli interrupt ıdi page fault e il bit reale di presenza/assenza sia un altro. E’ necessarioquindi anche modificare la logica di gestione delle pagine presenti/in swapper utilizzare questo bit e non quello standard [15]. Per trasferire la traccia di indirizzi dal kernel ad un processo in userspace ` indicato utilizzare un device a caratteri. In tale modo possono essere eprocessati ed analizzati dai tool descritti in precedenza senza dover effettuarescrittura su disco anche in questo caso.7.3.3 VirtualizzazioneNel caso di sistemi nei quali le applicazioni girino in ambiente virtualizzatosi pu` intervenire sul software di virtualizzazione affinch` esso produca la o esequenza di indirizzi necessaria all’analisi. In caso di sistemi di virtualiz-zazione open source come kvm ` possibile modificare direttamente il codice edi gestione della memoria per produrre la traccia di indirizzi virtuali delsistema client. In caso di software di virtualizzazione proprietari ` richiesta ela presenza di API [16] per ottenere tali informazioni. 66
  • 66. Figura 7.3: Il sistema monitorato ` virtualizzato e si utilizzano API del elayer di virtualizzazione per generale la sequenza di indirizzi 67
  • 67. 68
  • 68. Capitolo 8ConclusioneL’obiettivo che ci siamo prefissi ` stato quello di realizzare uno strumento esoftware che permettesse la classificazione dei workload in relazione alle met-riche di accesso alla memoria per arrivare fondamentalmente a due risultati: • stabilire delle caratteristiche statistiche dei diversi workload e riuscire a classificarli • stabilire istante per istante un algoritmo di riconoscimento del work- load in modo da poter costruire un sistema di allocazione di pagine di memoria di tipo adattativoQuesti due obiettivi sono stati raggiunti e sono state gettate le basi per lacostruzione di nuovi sistemi di ottimizzazione adattiva di un processo inesecuzione. Questo studio ha messo in evidenza vari risultati, cio`: e • i processi in esecuzione possono essere rappresentati dalla sequenza di indirizzi virtuali generata dai processi stessi • i processi visti come sequenze di indirizzi possono essere interpretati spettralmente • descrivendo le sequenze con parametri ottenuti dalla trasformata del coseno, i processi possono essere riconosciuti con buona accuratezza • la classificazione pu` essere effettuata in tempo reale con bassa comp- o lessit` computazionale a Le sperimentazioni effettuate hanno quindi dimostrato che le classifi-cazioni ottenute con i modelli statistici di Markov sono promettenti. Questorisultato apre tutta una serie di prospettive di sviluppi futuri, in linea con leultime tendenze della ricerca per quanto riguarda l’ottimizzazione dei siste-mi di calcolo. L’utilit` di questi risultati sta nel fatto che ` possibile eseguire a euna classificazionedel workload in tempo reale e quindi possibile usare questa 69
  • 69. classificazione per ottimizzare alcuni parametri del kernel del sistema, comead esempio la gestione della memoria. Oltre alla possibilit` di classificare un processo in esecuzione, la soluzione aproposta presenta delle caratteristiche che fanno pensare ad altre possibiliapplicazioni, come ad esempio quella di monitorare un processo in esecuzioneper verificare se sia veramente quella che dichiara di essere oppure per con-trollare che non cambi natura, segno che ad esempio potrebbe essere sogget-ta di un attacco da parte di un processo malizioso. In questo caso sarebbebene bloccare l’esecuzione prima che comporti dei danni. Questo tipo diapplicazioni verranno studiate in futuro. Una estensione dell’approccio descritto consiste nel considerare non so-lo parametri derivati dalle sequenze di indirizzi ma anche altri parametriderivati dall’uso dell’I/O da parte dei processi. Un ulteriore evoluzione diquesta ricerca potrebbe essere quella di considerare altre metriche di memo-ria e altri parametri rappresentativi per confrontare le prestazioni del sistemaadattativo nei vari casi. 70
  • 70. Appendice ADocumentazione tools offlineA.1 train, testtrain legge una traccia con la quale addestra modelli hmm e genera file relativi ai centroidi e al modello.test con in input un modello hmm, un file di centroidi e una traccia stampa la probabilit` che la traccia appartenga al modello. aUso da linea di comando./train [options] <tracefile>./test [options] -C [centroids file] -H [hmm file] <tracefile>-w <int> numero di blocchi di indirizzi da processare, def 1000-d <int> numero di indirizzi per blocco, default 1024-v <int> dimensione dei vettori da quantizzare, default 16-c <int> numero di centroidi, default 64-n <int> numero di stati della hmm, default 12-s <int> offset dal quale iniziare l’analisi, default 0-D <string> output directory, default "/tmp"Scriptssinglerun.rb effettua l’addestramento di un modello hmm con una traccia e lo testa con tutte le tracce. Multithreaded, produce grafici.fullrun.rb effettua l’addestramento di un modello hmm con ogni traccia, poi viene effettuato il test di ogni traccia su ogni modello. Multi- threaded, produce grafici.bruteforce.rb effettua l’addestramento di un modello hmm con ogni trac- cia, poi viene effettuato il test di ogni traccia su ogni modello. Il pro- cedimento viene ripetuto per diversi valori di window size, centroidi, 71
  • 71. stati per cercare i migliori parametri di addestramento. Multithreaded, produce (molti) grafici.A.2 genset zero, genset one, ntrain, ntestgenset one legge una traccia, la divide in settori e genera un insieme di N esempi per essere utilizzati come input corretto della rete neurale e un file di centroidi.genset zero legge una traccia e genera un insieme di M esempi da essere utilizzati come input della rete neurale per il quale si desidera output zero utilizzando i centroidi calcolati con genset one.ntrain addestra una rete neurale e la salva su file.ntest con in input un esempio generato da genset zero o genset one e un modello di rete calcola l’output applicando l’esempio agli input della rete.Uso da linea di comandousage: ./genset_one -s seek -D directory <trace.bin>usage: ./genset_zero -s seek -D dir -C <input.ctr> <trace.bin>usage: ./ntrain -G <good.set> <bad.set> <bad.set>...usage: ./ntest -D directory -N <input.net> <test.set>Scriptssingletest.rb effettua l’addestramento di una rete neurale con una traccia e la testa con tutte le tracce. Vengono effettuati 200+ test e scartati i risultati agli estremi superiore e inferiore. Produce grafici.multitest.rb effettua l’addestramento di una rete neurale con ogni traccia e poi le testa con tutte le tracce. Vengono effettuati 200+ test e scartati i risultati agli estremi superiore e inferiore. Multithreaded, produce grafici.matrixtest.rb Esegue singlerun.rb variando i parametri della rete per trovare i valori di addestramento ottimali. Multithreaded, produce grafici. 72
  • 72. Appendice BDocumentazione toolsValgrindB.1 tracebinEstensione di valgrind che genera le tracce in formato ascii e/o binario sufile o su stdout.Uso da linea di comandousage: valgrind --tool=tracebin [options] prog-and-args --std=yes|no enable traditional output [yes] --din=filename write trace in a dinero traditional format file --bin=filename write trace in a binary fileB.2 tracehmmtracehmm applica la parametrizzazione spettrale ed esegue apprendimentoe test di hmm utilizzando direttamente gli indirizzi di memoria via via chevengono generati dai benchmark.Uso da linea di comandousage: valgrind --tool=tracehmm [options] prog-and-args --new=<model.hmm> train a new hmm model --resume=<model.hmm> resume training --test=<model.hmm> test hmm model --centroids=<model.ct> centroids file --skip=<int> memory blocks to skip --window=<int> window size --verbose=yes|no verbose [yes] 73
  • 73. --vverbose=yes|no very verbose [no] --ct-n=<int> num of centroids --st-n=<int> num of statusesScriptsbenchmarks.rb incapsulamento in una classe Benchmark dei benchmark Spec. Ogni oggetto di tipo Benchmark ha associata la directory con i file di input e l’eseguibile, il nome dell’eseguibile, un array di linee di comando per lanciare il benchmark con i diversi input. Includendo questo file negli altri script ` possibile accedere all’array $benchmarks e contenente 12 oggetti di tipo Benchmark. Da configurare con il path dei benchmark Spec. # ricerca di gcc b= $benchmarks.find(lambda{die "not found"}) do |el| el.name.eql? "gcc" end puts b.rand_cmd # stampa comando casuale b.each_cmd do |cmd| # al blocco vengono passati # uno ad uno tutti i comandi # per essere eseguiti dalla classe Hmm puts cmd endbenchmarks-4.rb includendo questo file negli altri script ` possibile ac- e cedere all’array $benchmarks contenente un set ridotto di 4 oggetti di tipo Benchmark.hmm.rb incapsulamento in una classe Hmm dell’utilizzo del tool Valgrind tracehmm: offre metodi di addestramento e test dei benchmarks. Le variabili d’istanza degli oggetti di classe Hmm permettono di man- tenere gli stessi centroidi e modello tra l’esecuzione di un addestrma- mento e le successive. Sono configurabili tutti i parametri di addestr- mento. h= Hmm.new "path-to-valgrind" h.verbose= true h.out_dir = "models-output-directory" h.window= 2000 h.skip= 1000 h.train "cmd-to-run" # genera centroidi e modello 74
  • 74. h.resume "another-cmd" # continua l’addestramento # test result= h.test "another-cmd-even-from-other-benchmarks"train.rb effettua l’addestramento di un modello hmm. Produce file dei cen- troidi e del modello. Da configurare con il path della versione custom di Valgrind con tracehmm.train-all.sh effettua l’addestramento di modelli per tutti i benchmark es- eguendo train.rb.verification.rb esegue un test di verifica su un benchmark. Richiede in input il nome del benchmark da testare. Produce grafici.full-verification.rb esegue un test di verifica su tutti i benchmark. Richiede in input la directory contenente modelli e centroidi prodotti da train.rb. Produce grafici.classification.rb esegue un test di classificazione su tutti i benchmark. Richiede in input la directory contenente modelli e centroidi prodotti da train.rb. Produce grafici.bf.rb esegue test di verifica variando i parametri di addestramento per trovare valori ottimali. Richiede in input la directory contenente mod- elli e centroidi prodotti da train.rb. Produce grafici.cmatrix.rb produce la matrice di confusione di un test di classificazione in formato HTML.plot.rb contiene la classe Plot che viene utilizzata dagli altri script per generate grafici dallo stile uniforme.plot2.rb refactoring di plot.rb facendo uso di programmazione funzionale, vedi plot.rbarray-plus.rb funzioni helper di manipolazione arrays.reg-tests.rb esegue 240 regression tests sul tool di Valgrind tracehmm per verificare che l’ultima versione di sviluppo funzioni correttamente. 75
  • 75. 76
  • 76. Bibliografia[1] Ning Li and Shun-Zheng Yu. Periodic hidden markov model-based workload clustering and characterization. In Computer and Information Technology, 2008. CIT 2008. 8th IEEE International Conference on, pages 378 –383, 2008.[2] M. Calzarossa and G. Serazzi. Workload characterization: a survey. Proceedings of the IEEE, 81(8):1136 –1150, August 1993.[3] Ken J. McDonell. Benchmark frameworks and tools for modelling the workload profile. Performance Evaluation, 22(1):23 – 41, 1995. 6th International Conference on Modelling Techniques and Tools for Computer Performance Evalution.[4] A. Moro, E. Mumolo, M. Nolich. Ergodic Continuous Hidden Markov Models for workload characterization. 2009 Proceedings of 6th Interna- tional Symposium on Image and Signal Processing and Analysis, pages 99–104, September 2009.[5] Leonard E. Baum, Ted Petrie, George Soules, and Norman Weiss. A maximization technique occurring in the statistical analysis of prob- abilistic functions of markov chains. The Annals of Mathematical Statistics, 41(1):pp. 164–171, 1970.[6] Jr. Forney, G.D. The viterbi algorithm. Proceedings of the IEEE, 61(3):268 – 278, 1973.[7] Nicholas Nethercote and Julian Seward. Valgrind: A Framework for Heavyweight Dynamic Binary Instrumentation. Proceedings of ACM SIGPLAN 2007 Conference on Programming Language Design and Implementation, San Diego, California, USA, June 2007.[8] Valgrind source code. Valgrind Technical Documentation. URL: http://valgrind.org/docs/manual/index.html, 2010.[9] Nicholas Nethercote. Dynamic Binary Analysis and Instrumentation. PhD thesis, University of Cambridge, November 2004. 77
  • 77. [10] The Standard Performance Evaluation Corporation. SPEC CPU2006 Documentation. URL: http://www.spec.org/cpu2006/Docs/, 2006.[11] Gnu octave source code. http://www.octave.org.[12] Tapas Kanungo. Umdhmm: Hidden markov model toolkit. Extended Finite State Models of Language, 1999.[13] David MacKay. Information Theory, Inference, and Learning Algorithms. Cambridge University Press, 2003.[14] Chi-Keung Luk, Robert Cohn, Robert Muth, Harish Patil, Artur Klaus- er, Geoff Lowney, Steven Wallace, Vijay Janapa Reddi, Kim Hazelwood. Pin: Building Customized Program Analysis Tools with Dynamic In- strumentation. Programming Language Design and Implementation, Chicago, IL, pages 190–200, June 2005.[15] Robert Love. Linux Kernel Development. Novell Press, 2005.[16] Min Xu, Vyacheslav Malyugin, Jeffrey Sheldon, Ganesh Venkitachalam, Boris Weissman, and Vmware Inc. Retrace: Collecting execution trace with virtual machine deterministic replay. In In Proceedings of the 3rd Annual Workshop on Modeling, Benchmarking and Simulation, MoBS, 2007. 78

×