• Curs 10 - Dispozitive de Intrare/Iesire (Prezi)
• Curs 10 - Dispozitive de Intrare/Iesire (PDF)

• Suport curs
  • Operating Systems Concepts
  • Capitolul 13 – I/O Systems
  • Capitolul 12 – Mass Storage Structure
    • Secțiunile 12.2, 12.4, 12.7
  • Modern Operating Systems
    • Capitolul 5 – Input/Output
      • Secțiunile 5.1, 5.2, 5.3
      • Subsecțiunile 5.4.1, 5.4.3

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

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

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