Differences

This shows you the differences between two versions of the page.

Link to this comparison view

so:cursuri:curs-05 [2013/03/18 21:14]
razvan.deaconescu
so:cursuri:curs-05 [2019/03/15 09:46] (current)
razvan.deaconescu
Line 1: Line 1:
-====== Curs 05 - Sincronizarea proceselor ​======+====== Curs 05 - Gestiunea memoriei ​======
  
-<​html>​ +  * [[http://​prezi.com/​gfswijyf3vsk/?utm_campaign=share&utm_medium=copy&rc=ex0share | Curs 05 - Gestiunea memoriei (vizualizare Prezi)]] 
-<iframe src="http://​prezi.com/​embed/​wvn6csoot1iw/?bgcolor=ffffff&amp;​lock_to_path=0&amp;​autoplay=no&​amp;​autohide_ctrls=0&​amp;​features=undefined&​amp;​disabled_features=undefined"​ width="​550"​ height="​400"​ frameBorder="​0"></​iframe>​ +  * [[http://​elf.cs.pub.ro/​so/​res/​cursuri/​SO_Curs-05.pdf | Curs 05 - Gestiunea memoriei (PDF)]]
-</html>+
  
-  * [[http://prezi.com/wvn6csoot1iw/so-curs-5/?kw=view-wvn6csoot1iw&​rc=ref-31844697 ​Curs 05 - Sincronizarea proceselor (vizualizare Prezi)]] +  * [[https://docs.google.com/document/d/19vfKQ4PRci64ZKHzrELigoygpLIkw1ZLGczmCpeS8kU/​edit?usp=sharing|Notițe de curs]]
-  * [[http://​elf.cs.pub.ro/​so/​res/​cursuri/​SO_Curs-05.pdf | Curs 05 - Sincronizarea proceselor (PDF)]]+
  
   * Suport curs   * Suport curs
     * Operating System Concepts Essentials     * Operating System Concepts Essentials
-      * Capitolul ​Process Synchronization +      * Capitolul ​Main Memory 
-        * Secțiunile ​6.1-6.56.6.16.6.26.8.2-6.8.4 +    * Modern Operating Systems, 2nd Ed. 
-      * Capitolul 7 - Deadlocks +      * Capitolul 4 - Memory Management 
-    * Modern Operating Systems +        * Secțiunile ​4.1, 4.24.34.8 
-      * Capitolul ​Processes and Threads +    * Modern Operating Systems, 3rd Ed. 
-        * Secțiunile ​2.3.1-2.3.62.3.92.4.2 +      * Capitolul ​Memory Management 
-      * Capitolul ​3 - Deadlocks +        * Secțiunile 3.1, 3.2, 3.3, 3.
-    * Little Book of Semaphores +    * [[http://​lwn.net/​Articles/​250967/​ | Ulrich Drepper - What every programmer should know about memory]] 
-      * Capitolele 123 + 
-      * Capitolul 4 +<​html>​ 
-        * Secțiunile 4.1, 4.2+  <​center>​ 
 +    <iframe src="​https://​prezi.com/​embed/​gfswijyf3vsk/?​bgcolor=ffffff&​amp;​lock_to_path=0&​amp;​autoplay=0&​amp;​autohide_ctrls=0&​amp;​features=undefined&​amp;​disabled_features=undefined"​ width="​550"​ height="​400"​ frameBorder="​0"​ webkitAllowFullScreen mozAllowFullscreen allowfullscreen></​iframe>​ 
 +  </​center>​ 
 +</​html>​ 
 + 
 +===== Demo-uri ===== 
 + 
 +Pentru parcurgerea demo-urilorfolosim [[http://​elf.cs.pub.ro/​so/​res/​cursuri/​curs-05-demo.zip|arhiva aferentă]]. Demo-urile rulează pe Linux. Descărcăm arhiva folosind comanda<​code bash> 
 +wget http://​elf.cs.pub.ro/​so/​res/​cursuri/​curs-05-demo.zip 
 +</​code>​ și apoi decomprimăm arhiva<​code bash> 
 +unzip curs-05-demo.zip 
 +</​code>​ și accesăm directorul rezultat în urma decomprimării<​code bash> 
 +cd curs-05-demo/​ 
 +</​code>​ 
 + 
 +Acum putem parcurge secțiunile cu demo-uri de mai jos. 
 + 
 +==== Informații despre memoria sistemului ==== 
 + 
 +Ca să aflăm informații despre memoria RAM (fizică) disponibilă pe sistem folosim comanda<​code bash> 
 +free -m 
 +</​code>​ 
 +Rezultatul afișat este în megaocteți. 
 + 
 +Altă variantă este consultarea fișierului ''/​proc/​meminfo'':<​code bash> 
 +cat /​proc/​meminfo 
 +</​code>​ 
 + 
 +Spațiul de adresare disponibil îl putem afla prin consultarea fișierului ''/​proc/​cpuinfo'':<​code bash> 
 +cat /​proc/​cpuinfo | grep '​address sizes'​ 
 +</​code>​ 
 +Ni se vor afișa informații despre spațiul adresabil fizic și cel virtual. În generalla sistemele cu arhitectură x86_64, deși registrele sunt pe 64 de biți, spațiul adresabil virtual este de 48 de biți. 
 + 
 +Pentru a afla informații desre memoria cache a sistemului, folosim comanda<​code bash> 
 +lscpu 
 +</​code>​ și urmărim liniile care conțin cuvântul ''​cache''​Sau folosim comanda<​code bash> 
 +getconf -a | grep '​CACHE'​ 
 +</​code>​ 
 +De obicei avem mai multe niveluri de memorie cache. Primul nivel conține în general un cache pentru date și unul pentru instrucțiuni. 
 + 
 +Pentru a afla dimensiunea paginii sistemului folosim comanda<​code bash> 
 +getconf PAGE_SIZE 
 +</​code>​ 
 + 
 +Programatic,​ astfel de informații pot fi determinate prin intermediul apelului [[http://​man7.org/​linux/​man-pages/​man3/​sysconf.3.html|sysconf]]. O implementare succintă se găsește în subdirectorul ''​system-memory/''​. În fișierul ''​system-memory.c''​ folosim apelul ''​sysconf''​ pentru a afla dimensiunea paginii sistemului, spațiul de memorie, informații despre memoria cache. Pentru a folosi programul, îl compilăm și îl rulăm:<​code bash> 
 +make 
 +./​system-memory 
 +</​code>​ 
 + 
 +==== Informații despre spațiul de adresă al unui proces ==== 
 + 
 +Spațiul de adresă al unui proces poate fi vizualizat folosind comanda ''​pmap''​. De exempludacă dorim să vizualizăm spațiul de adresă al procesului curent folosim comanda<​code bash> 
 +pmap $$ 
 +</​code>​ 
 +Spațiul de adresă al unui proces cuprinde zona de cod/text (marcată ''​r-x''​)zone de date (marcate ''​r<​nowiki>​--</​nowiki>''​ și ''​rw-''​),​ biblioteci partajate, heap, stivă. 
 + 
 +Spațiul de adresă al procesului este modificat dinamic (la //​runtime//​) prin alocare și dezalocare de memoriePentru a urmări modul în care este alterat spațiul de adresă al procesului la alocare și dezalocare folosim programul din subdirectorul ''​address-space/''​. 
 + 
 +În fișierul ''​address-space.c''​ alocăm și dezalocăm memorie folosind stiva (la un apel de funcție), apelurile ''​malloc''​ și ''​free'',​ respectiv apelurile ''​mmap''​ și ''​munmap''​. Înaintea executării unui pas programul așteaptă 5 secunde, timp în care putem urmări evoluția spațiului de adresă. 
 + 
 +Pentru a urmări evoluția programului avem nevoie de două console. Într-o consolă compilăm și rulăm programul, iar în alta verificăm funcționalitatea sa folosind ''​pmap''​. 
 + 
 +Pentru acesta în prima consolă compilăm și rulăm:<​code bash> 
 +make 
 +./​address-space 
 +</​code>​ 
 +Apoi, în cealaltă consolă rulăm periodic comanda:<​code bash> 
 +pmap $(pidof address-space) 
 +</​code>​ 
 + 
 +Observăm cum se modifică dimensiunile diverselor regiuni după alocare. Stiva nu se modifică; stiva este deja alocată iar spațiul ocupat de ''​buffer''​ nu conduce la alterarea stivei. Pentru ''​malloc''/''​free''​ și ''​mmap''/''​munmap''​ se alocă/​eliberează dimensiunea cerută în conformitate cu apelul. 
 + 
 +==== Granularitatea alocării de memorie ==== 
 + 
 +Deși un apel de genul ''​malloc''​ permite alocare fină de memorie (de nivelul octeților),​ în spate sistemul de operare și hardware-ul alocă memorie la nivel de pagină. Un apel de alocare a memoriei va aloca mai mult spațiu pentru a permite viitoare alocări. 
 + 
 +Pentru a verifica acest lucru folosim subdirectorul ''​allocation-granularity/''​. Fișierul ''​allocation-granularity.c''​ este un program care primește ca argument dimensiunea care să fie transmisă apelului ''​malloc''​ și apoi așpteaptă 5 secunde înainte și după pentru a putea urmări efectul acestei alocări asupra spațiului de adresă, după care procesul este închis. 
 + 
 +Vom folosi două console: pe o consolă vom rula programul iar pe alta vom investiga spațiul de adresă aferent. Pentru aceasta pe prima consolă vom compila și vom rula procesul:<​code bash> 
 +make 
 +./​allocation-granularity ​1 
 +</​code>​ în vreme ce pe a doua consolă vom consulta spațiul de adresă al procesului:<​code bash> 
 +pmap $(pidof allocation-granularity) 
 +</​code>​ 
 + 
 +Prima comandă alocă un singur octet în mod dinamic în cadrul spațiului de adresă. Ultima comandă o vom rula de mai multe ori pentru a verifica modul în care se modifică spațiul de adresă al procesului. Vedem că la o simplă alocare de 1 octet se alocă o zonă mai mare în spațiul de adresă al procesuluiconform modului intern de lucru al apelului de bibliotecă ''​malloc''​. 
 + 
 +==== Informații despre TLB ==== 
 + 
 +Pentru a afla informații despre TLB instalăm pachetul ''​cpuid''​. Pe un sistem Debian-based folosim comanda<​code bash> 
 +apt-get install cpuid 
 +</​code>​
  
-/*+Ca să determinăm informații despre TLB folosim comanda<​code bash> 
 +cpuid | grep TLB 
 +</code>
  
-===== Răspunsuri întrebări curs =====+Dacă vrem să urmărim numărul de miss-uri pentru TLB putem folosi ''​perf''​. De exemplu, pentru a urmări TLB miss-urile într-un interval de 10 secunde la nivelul sistemului folosim comanda<​code bash> 
 +sudo perf stat -e iTLB-load-misses -a sleep 10 
 +</​code>​
  
-  ​Un proces poate fi planificat într-un kernel non-preemptiv ​în momentul ​în care execută cod kernel dacă: +TLB miss-urile cresc în momentul ​schimbării spațiului de adresă, adică la planificarea proceselor. Dacă avem multe schimbări de spațiu de adresă între ​procese ​atunci numărul de TLB miss-uri va crește. Pentru a verifica acest lucru, din [[http://​elf.cs.pub.ro/so/res/cursuri/​curs-04-demo.zip|arhiva laboratorului 4]], din subdirectorul ''​nice/''​ rulăm scriptul ''​start-all'' ​(după ce am compilat în prealabil executabilul ''​cpu''​). După ce am rulat scriptul folosim o altă consolă pentru ​măsura numărul de TLB miss-urifolosind aceeași comandă ca mai sus:<​code bash> 
-     * procesul execută o operație blocantă (blocare la un semafor, alocare ​de memorie care necesită swappinglucru cu un dispozitiv periferic) +sudo perf stat -e iTLB-load-misses -sleep 10 
-     * procesul se termină +</​code>​
-  - Există următoarea situație: trebuie planificat un proces cu prioritate mică este si mai multe de procese cu prioritate mai mare, care vin în continuu. Fiind prioritați statice, procesul cu prioritate mai mică nu va fi ales niciodată, mereu existând alte procese ​cu prioritate mai mare, acest lucru conducând la starvation. Soluția o reprezintă utilizarea ​de priorități dinamice care să ia în considerare timpul petrecut de un proces în coada de așteptare ​se mărește prioritate pe odata cu vechimea. +
-  - Apelurile IO blocante genereaza contex switchCitirea și deschiderea unui fișier sunt în mod normal blocante și se va apela planificatorul de procese.\\ Operatia V pe un semafor = acquire()Daca semaforul nu poate fi luat, apelul este blocant, procesul/treahdul este pus în coada waiting a semaforului și alt proces/thread este planificat.\\ Operatia P pe un semafor = release(). Dacă sunt procese/​threaduri care așteaptă eliberarea semforuluiatunci unul din aceastea va fi ales și trecut în starea de ready, urmând ​fi planificat ulterior. +
-  *+
  
-~~DISCUSSION:​off~~+Observăm un număr semnificativ mai mare de TLB miss-uri datorat numeroaselor schimbări de context ce au loc între procesele pornite de scriptul ''​start-all'​.
so/cursuri/curs-05.1363634087.txt.gz · Last modified: 2013/03/18 21:14 by razvan.deaconescu
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0