This is an old revision of the document!
Pentru parcurgerea demo-urilor, folosim arhiva aferentă. Demo-urile rulează pe Linux. Descărcăm arhiva folosind comanda
wget http://elf.cs.pub.ro/so/res/cursuri/curs-10-demo.zip
și apoi decomprimăm arhiva
unzip curs-10-demo.zip
și accesăm directorul rezultat în urma decomprimării
cd curs-10-demo/
Acum putem parcurge secțiunile cu demo-uri de mai jos.
Dorim să investigăm livrarea întreruperilor hardware către sistemul local. Vom urmări întreruperea de ceas (timer) și întreruperea de tastatură.
În Linux fișierul care afișează informații despre tastatură este /proc/interrupts
. În acest fișier sunt afișate informații statistice despre întreruperilor livrate, câte o coloană pentru fiecare procesor. În cadrul fișierului găsim informații și despre întreruperea de ceas și cea de tastatură:
$ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 14 0 0 0 IR-IO-APIC-edge timer 1: 1358967 0 0 0 IR-IO-APIC-edge i8042 [...] LOC: 96023026 47877718 90900926 54219891 Local timer interrupts [...]
Prima coloană este linia de întrerupere (IRQ line
) pe care se livrează semnalul de întrerupere către procesor. Este 0 în cazul timer-ului programabil (8253) și 1 în cazul controller-ului de tastatură (8042).
Din output-ul comenzii de mai sus am selectat doar intrările referitoare la întreruperea de ceas (timer
și Local timer interrupts) și cea de tastatură (i8042
). La noi rulări ale comenzii
cat /proc interrupts
vom observa actualizări ale valorilor întreruperilor. În figura de mai sus întreruperea de tastatură (i8042
) este tratată doar pe primul procesor (CPU0
) în vreme ce există întreruperi de ceas locale pentru fiecare procesor (de unde și denumirea de local).
Pe sistemele multi-core/multiprocesor se folosesc întreruperile de ceas locale (cele indicate de Local timer interrupts). Acestea sunt livrate de controller-ul de întreruperi (APIC) către fiecare procesor în parte. Din acest motiv există actualizări pentru linia identificată de LOC:
dar nu și pentru timer-ul programabil de pe linia identificată cu timer
. Pe sisteme uniprocesor, pentru livrarea întreruperii de ceas se folosește timer-ul programabil.1)
Informațiile despre întreruperea de ceas sunt actualizate periodic în fișierul /proc/interrupts
pentru că la un interval dat se livrează o nouă întrerupere.
Întreruperile de tastatură sunt livrate la fiecare apăsare de tastă. Pentru a investiga evoluția numărului de întreruperi de tastatură livrate, tastăm șirul de comenzi de mai jos:
$ cat /proc/interrupts | grep ' 1:' 1: 1366012 0 0 0 IR-IO-APIC-edge i8042 $ echo 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa $ cat /proc/interrupts | grep ' 1:' 1: 1366184 0 0 0 IR-IO-APIC-edge i8042
Între prima afișare și a doua afișare a conținutului fișierul /proc/interrupts
am tastat circa 70-80 de taste pentru comanda echo …
și a doua comandă cat
(am mai apăsat și pe tasta Backspace când am greșit). Observăm că diferența între cele două rezultate (întreruperi livrate) este 1336184 - 1336012 = 172
. Au fost livrate circa dublu de întreruperi față de tastele apăsate. Acest lucru se întâmplă pentru că se livrează o întrerupere pentru fiecare apăsare de tastă (key press) și una pentru fiecare eliberare de tastă (key release); de unde și numărul dublu de întreruperi livrate față de taste apăsate.
Dorim să urmărim efectul cache-ul de disk (numit și page cache). Acesta stochează datele frecvent accesate în memorie astfel că viitoare folosiri ale acestora să fie mai rapide. Vom copia de două ori un fișier și vom observa că a doua oară copierea este mai rapidă datorită cache-ului.
Creăm un fișier in.dat
de 100MB de date aleatoare folosind comanda dd
:
$ dd if=/dev/urandom bs=1M count=100 of=in.dat 100+0 records in 100+0 records out 104857600 bytes (105 MB) copied, 7.14143 s, 14.7 MB/s
Apoi copiem fișierul in.dat
în fișierul out.dat
folosind comanda cp
și măsurând durata de execuție cu ajutorul comenzii time
:
razvan@einherjar:~$ /usr/bin/time -v cp in.dat out.dat Command being timed: "cp in.dat out.dat" User time (seconds): 0.00 System time (seconds): 0.09 Percent of CPU this job got: 100% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.09 [...] Voluntary context switches: 1 Involuntary context switches: 2 Swaps: 0 File system inputs: 0 File system outputs: 204800 [...]
Observăm ca a durat foarte puțin copierea, sub 10
milisecunde în rularea de mai sus. Aceasta s-a întâmplat pentru că fișierul in.dat
a fost cache-uit în page cache de la rularea comenzii dd
, când a fost generat.
Ca să urmărim ce se întâmplă când fișierul nu se găsește în page cache, facem flush la page cache și apoi invalidăm intrările folosind comenzile de mai jos:
$ free -m total used free shared buffers cached Mem: 7893 4715 3178 251 728 1687 -/+ buffers/cache: 2299 5593 Swap: 3813 427 3386 $ sudo sync $ echo 1 | sudo tee /proc/sys/vm/drop_caches 1 $ free -m total used free shared buffers cached Mem: 7893 2653 5240 251 0 397 -/+ buffers/cache: 2255 5637 Swap: 3813 427 3386
Am folosit comanda free
doar pentru a raporta folosirea bufferelor și a cache-ului. După rularea comenzilor sync
și echo …
observăm eliberarea completă a bufferelor și aproape compleă a cache-ului.2)
Copiem din nou fișierul in.dat
într-un nou fișier out2.dat
și folosim comanda time
pentru a măsura durata:
$ /usr/bin/time -v cp in.dat out2.dat Command being timed: "cp in.dat out2.dat" User time (seconds): 0.00 System time (seconds): 0.22 Percent of CPU this job got: 11% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:02.02 [...] Voluntary context switches: 451 Involuntary context switches: 11 Swaps: 0 File system inputs: 205632 File system outputs: 204800 [...]
Observăm că acum operația durează semnificativ mai mult (2 minute). De asemenea încărcarea pe procesor este mai mică (11%
față de 100%
pentru că acum procesorul așteaptă după disc. Observăm diferența mare de schimbări de context voluntare (procesul se blochează) și numărul diferit de zero de citiri din sistemul de fișiere: acum întreg fișierul de intrare este citit de pe disc, nu mai este cache-uit în memorie.
Cache-ul de disk este esențial pentru funcționarea eficientă a sistemului. În absența acestuia procesorul ar trebui să solicite informații de pe disc, dispozitiv foarte lent comparativ cu memoria și procesor. Trebuie avut grijă la flush-ul/sincronizarea periodică a informațiilor din memorie pe disc pentru ca acestea să nu se piardă la o închidere bruscă a sistemului, memoria fiind volatilă.
Dorim să urmărim ce se întâmplă în cazul în care avem date partajate într-un mediu multithread. Pentru aceasta accesăm subdirectorul list-excl/
; urmărim conținutul fișierelor thread-list-app.c
și list.c
. Este vorba de o aplicație care lucrează cu liste înlănțuite într-un mediu multithreaded. Vom observa că există riscul ca datele să fie corupte, fiind necesară sincronizare.
Compilăm fișierele folosind make
. Rezultă două fișiere în format executabil: thread-list-app
și thread-list-app-mutex
.
Programul thread-list-app-mutex
folosește intern un mutex pentru sincronizare. Pentru aceasta folosim macro-ul USE_MUTEX
pe care îl definim în fișierul Makefile
.
Ca să urmărim ce se întâmplă cu o aplicație multithreaded cu date partajate, rulăm de mai multe ori programul thread-list-app
, până la obținerea unei erori:
./thread-list-app
Dorim să urmărim ce se întâmplă în cazul în care avem date partajate într-un mediu multithread. Pentru aceasta accesăm subdirectorul list-excl/
; urmărim conținutul fișierelor thread-list-app.c
și list.c
. Este vorba de o aplicație care lucrează cu liste înlănțuite într-un mediu multithreaded. Vom observa că există riscul ca datele să fie corupte, fiind necesară sincronizare.
Compilăm fișierele folosind make
. Rezultă două fișiere în format executabil: thread-list-app
și thread-list-app-mutex
.
Programul thread-list-app-mutex
folosește intern un mutex pentru sincronizare. Pentru aceasta folosim macro-ul USE_MUTEX
pe care îl definim în fișierul Makefile
.
Ca să urmărim ce se întâmplă cu o aplicație multithreaded cu date partajate, rulăm de mai multe ori programul thread-list-app
, până la obținerea unei erori:
./thread-list-app