Solutie Pentru Monitorizarea Schimbarilor Starilor de Consum ale Unui Sistem de Calcul Folosind Tehnologia Intel Speedstep

Cuprins

Introducere

Arhitectura ACPI

Scopuri principale

Raționamentul pentru power management

Structura ACPI

Stările sistemului și stările dispozitivelor

Stările golbale de sistem (Global System States)

Stările de putere ale dispozitivelor (Device Power States)

Stările de Sleep

Stările de putere ale procesorului (Processor power states)

Stările de performanță ale procesorului și dispozitivelor (Device and Processor Performance States)

System Power Management

Consumul de energie în procesor

Dynamic voltage scaling

Dynamic frequency scaling

SpeedStep

Arhitectura driverelor Windows

Structura unui IRP

Stiva I/O

Tranzițiile stărilor de consum

Proiectarea aplicației

Design

Implementare

Testare

Rezultate

Concluzii

Bibliografie

1. Introducere

Power managementul sistemelor de calcul este un aspect important în informatică, fie că se dorește obținerea unor performanțe mai bune prin overvolting (overclocking), fie că se dorește obținerea unui consum mai redus de energie. Un consm redus implică prelungirea vieții bateriei pentru sistemele mobile și embedded, reducerea cerințelor de răcire, reducerea zgomotului produs de sistemele de răcire.

Tehnologiile prezente (AMD Cool’n’Quiet, AMD PowerNow!, IBM EnergyScale, Intel SpeedStep) permit utilizatorului să aibă un anumit grad de control asupra power managementului în sistemul de operare. Stările de consum în care se poate afla un sistem se stabilesc în funcție de necesitățile computaționale ale sistemului sau după dorința utilizatorului.

Lucrarea prezintă o soluție pentru monitorizarea schimbărilor stărilor de consum ale unui sistem de calcul folosind tehnologia Intel SpeedStep.

2. Arhitectura ACPI

Specificațiile Advanced Configuration and Power Interface (ACPI), au fost elaborate pentru a stabili interfețe commune în sistemul de operare care să permit o configurare robustă si power managementul atât al dispozitivelor individuale aflate pe o placă de bază cât și al unui sistem întreg.

ACPI a evoluat de la colecția de cod pentru power management a BIOS-ului, interfețe de programare pe aplicații(API-uri, PNPBIOS API-uri, tabele de specificații multiprocessor MPS), intr-un set de specificații bine definite pentru interfețe de configurare si power management.

ACPI oferă mijloacele pentru o tranziție ordonată de la hardware-ul existent la hardware-ul ACPI, și permite ambelor mecanisme să coexiste într-o singură mașină și să fie utilizate după cum este necesar.

2.1 Scopuri principale

ACPI este elementul cheie în punerea în implementarea OSPM(Operating System-directed configuration and Power Management). Interfețele ACPI sunt detonate unei folosințe cât mai largi pentru a încuraja furnizorii de hardware și software să dezvolte produse compatibilei ACPI (și astfel, compatibile OSPM).

Principalele scopuri ACPI și OSPM sunt:

Permiterea tuturor sistemelor de calcul să implementeze funcții de onfigurare si power management a plăcii de bază, folosind compromisurile cost/funcție corespunzătoare.

Sistemele de calcul includ(dar nu sunt limitate la) calculatoare desktop, sisteme mobile, stații de lucru ți servere.

Programatorii de mașini au libertatea de implementa o gamă largă de soluții, d ela cele mai simple la cele maia gresive, in tot acest timp având suportul deplin al sistemului de operare.

O implementare largă a power managementului va face ca acesta să fie practic, iar aplicațiile să îl suporte să îl exploateze. Va face ca utilizarea PC-urilor să fie mai economică.

Funcționalitatea de power management îmbunătățită si robustețea

Politici de power management prea complicate pentru a fi implementate în ROM BIOS pot fi implementate și suportate în sistemul de operare, permițând unei componente hardware cu power management redus să suporte politici de power management foarte elaborate.

Strângerea de informații de power management de la utilizator, aplicații si componente hardware la un loc în sistemul de operare permite luarea de decizii mai bune in privința power managementului.

Unificarea algoritmilor de power management in sistemul de operare reduce conflictele dintre firmware si sistemul de operare și îmbunătățește siguranța.

Facilitarea și accelerarea implementării power managementului la nivelul industriei

OSPM și ACPI reduce investițiile redundante pentru power management în industriei, pentru că aceste investiții se strâng la nivelul sistemului de operare. Aceasta permite participanților în industrie să iși concentreze eforturile și investițiile pentru inovații.

Sistemul de operare poate să evolueze independent de hardware, permițând tuturor mașinilor compatibile ACPI să beneficieze de îmbunătățirile sistemului de operare.

Crearea unei interfețe robuste pentru configurarea dispozitivelor de pe placa de bază

Permiterea unor proiectări avansate imposibil de realizat cu interfețele actuale.

2.2 Raționamentul pentru power management

Este necesară mutarea power managementului în sistemul de operare și folosirea unei interfețe abstracte (ACPI) între sistemul de operare și componentele hardware pentru a atinge scopurile definite anterior

Suport minim pentru power management determină producătorii de aplicații să suporte sau să exploateze power managementul.

Mutarea power managementului în sistemul de operare îl face disponibil pe orice mașină care are instalat un system de operare. Nivelul funcționalității variază de la o mașină la alta, dar utilizatorii și aplicațiile văd aceeași interfață și aceeași semantic de power management pe toate mașinile.

Aceasta permite producătorilor de aplicații să investească în adăugarea de funcționalități de power management aplicațiilor lor.

Algoritmii vechi de power management erau restricționați de către informațiile disponibile BIOS-ului care la implementa. Acest fapt limita funcționalitățile care puteau fi implementate.

Centralizarea informațiilor și directivelor de power management în sistemul de operare permite implementarea unor funcționalități mai puternice.

Funcții pentru aplicații, cum ar fi un robot telephonic, necesită decizii coerente globale de putere. De exemplu, un robot telefonic poate spune sistemului de operare că este în așteptare de apleluri telefonice și orice stare de cconsum (inclusive stări de sleep) pe care o are sistemul trebuie săa îi permită să răspundă intr-un anumit interval de timp (inclusive trezirea dintr-o eventual stare de sleep). Astfel, cand sistemul e pus intr-o stare de consum redus (sleep), sistemul va alege cea mai adâncă stare de sleep care satisface cerințele serviciului de preluare de apeluri telefonice.

Codul BIOS a devenit prea complex pentru a suporta și power management. Codul e limitat la configurația static a componentelor hardware.

Sunt mult mai puține date de stare pe care BIOS-ul trbuie să le rețină și gestioneze (pentru că sistemul de operare se ocupă de gestionarea lor).

Algoritmii de power management sunt unificași în sistemul de operare, oferind o integrare mai bună între sistemul de operare și componentele hardware.

Tabele ACPI adiționale (Definition Blocks) se pot încărca, de exemplu, când se atașseză sisteme mobile, astfel că sistemul de operare suportă o configurare dinamică a sistemelor.

Pentru că BIOS-ul are funcții mai puține și mai simple, e mult mai ușor (și mai ieftin) de implementat si întreținut.

Structura existentă a platformelor PC constrânge proiectarea sistemelor de operare și a componentelor hardware.

Deoarece ACPI este o interfață abstract, sistemul de operare poate evolua independent de sistemele hardware, și de asemenea, sistemele hardware pot evolua independent de sistemele de operare.

ACPI este mai portabil între sisteme de operare și procesoare. Metodele de control ACPI permit implementări flexibile pentru proprietăți amănunțite.

2.3 Structura ACPI

Specificațiile ACPI definesc interfețe ACPI hardware, interfețe ACPI software și structure de date ACPI. De asemenea, e definită și semantica acestor interfețe.

În figura 1.1 se prezintă componentele software și hardware relevante OSPM/ACPI și modul cum acestea sunt legate între ele. Specificațiile descriu interfețele dintre component, conținutul tabelelor de descriere a sistemului (ACPI System Description Tables) și semantic celorlalte component ACPI. Se observă că ACPI System Description Tables, care descriu hardware-ul unei anumite platform, sunt în central implementării ACPI și rolul principal al ACPI System Firmware este de a oferi date tabelelor ACPI.

ACPI nu este un set de specificații software, și nici un set de specificații hardware, deși se adresează atât software-ului cât și hardware-ului și cum trebuie acestea să interacționeze. ACPI este un et de specificații de interfețe ce elemente software și hardware.

Componentele ACPI

ACPI System description Tables

Descriu interfața către hardware. Unele descrieri limitează ce se poate construe( de exemplu, unele controlee sunt integrate in blocuri fixe de regiștri și tabele specific adresele acestor blocurilor). Majoritatea descrierilor permit hardware-ului să fie construit în mod arbitrar și pot descrie secvențe de operații arbitrare necesare funcționării hardware-ului. Tabelele ACPI care conțin Blocuri de Definire (Definition Blocks) pot folosi un limbaj de tip pseudo-cod, intrepretarea căruia se face de către sistemul de operare. Aceasta înseamnă că sistemul de operare conține și folosește un interpretor ce execută procedure codate în limbajul pseudo-cod și stocat în tabelele ACPI ce conțin Blocuri de Definire. Limbajul pseudo-cod, cunoscut sub numele de ACPI Machine Language (AML), este un tip compact și abstract de limbaj mașină.

Registrele ACPI

Partea constrânsă a interfeței hardware, descrisă (cel puțin locația) de către ACPI System Description Tables.

ACPI System Firmware

Se referă la partea de firmware care este compatibilă cu specificațiile ACPI. În general, acesta e codul care boot-ează mașina și implementează interfețele pentru sleep, wake și câteva dintre operațiile de restart. Este apelat rar, comparat cu BIOS-ul vechi. ACPI System Description Tables sunt de asemenea furnizate de către ACPI System Firmware.

3. Stările sistemului și stările dispozitivelor

3.1 Stările globale de sistem (Global System States)

Stările globale de sistem (Gx state) se aplică pentru întregul sistem și sunt vizibile pentru utilizator.

Stările globale de sistem sunt definite de către șase criterii principale:

1. Rulează software-ul vreunei aplicații?

2. Care este latența între un evenimente extern și la răspunsul cererii?

3. Care este consumul de energie?

4. Este necesară repornirea sistemului de operare pentru a reveni la o stare de lucru?

5. Este sigură desasamblarea computerului?

6. Poate să se intre și să se iasă din stare în mod electronic?

Lista de stări de sistem:

G3 Mechanical Off

O stare a computerului în care se intră și din care se iasă printr-un mijloc mecanic (de exemplu, oprirea alimentării prin mișcarea unui comutator roșu mare). Această satre implică faptul că nici un curent electric nu circulă prin circuitele computerului și că se poate lucra asupra hardware-ului fara a-l deteriora sau pune în pericol personalul de service. Sistemul de operare trebuie să fie repornit pentru a a reveni la starea de lucru. Nici un context hardware-ul nu este reținut. Cu excepția ceas de timp real, consumul de purtere este zero.

G2/S5 Soft Off

O stare a computerului în care acesta consumă o cantitate minimă de energie. Nu este executat nici cod în mod utilizator nici cod de sistem.Are nevoie de o lanență mare pentru a reveni la starea de lucru. Contextul sistemului nu va fi păstrat de către hardware. Sistemul trebuie să fie repornit pentru a reveni la starea de lucru. Nu este sigură dezasamblarea sistemului în această stare.

G1 Sleeping

O stare a computerului în care computerul consumă o cantitate mică de energie, nu se rulează fire de execuție în modul utilizatorului, iar sistemul "pare" să fie oprit (din punct de vedere al utilizatorului,i la starea de lucru. Nici un context hardware-ul nu este reținut. Cu excepția ceas de timp real, consumul de purtere este zero.

G2/S5 Soft Off

O stare a computerului în care acesta consumă o cantitate minimă de energie. Nu este executat nici cod în mod utilizator nici cod de sistem.Are nevoie de o lanență mare pentru a reveni la starea de lucru. Contextul sistemului nu va fi păstrat de către hardware. Sistemul trebuie să fie repornit pentru a reveni la starea de lucru. Nu este sigură dezasamblarea sistemului în această stare.

G1 Sleeping

O stare a computerului în care computerul consumă o cantitate mică de energie, nu se rulează fire de execuție în modul utilizatorului, iar sistemul "pare" să fie oprit (din punct de vedere al utilizatorului, ecranul este stins, și așa mai departe). Latenta pentru revenirea la starea de lucru variază în funcție de mediul de trezire selectate anterior de intrarea în această stare (de exemplu, dacă sistemul ar trebui să răspundă apelurilor telefonice). Starea de lucru poate fi reluată fără a reporni sistemul de operare deoarece elementele mari din contextul sistemului sunt salvate de hardware și restul de către software. Nu este sigură dezasamblarea sistemului în această stare.

G0 Working

O stare a computerului în care sistemului rulează aplicații în mod utilizator. În această stare, dispozitivelor periferice li se schimbă stările în mod dinamic. Utilizatorul poate selecta, prin intermediul unor interfețe utilizator (UI), diferite caracteristici de performanță și putere ale sistemului pentru a optimiza performanțele sau pentru a lungi durata de viață a bateriei. Sistemul răspunde la evenimente externe in timp real. Nu este în siguranță dezasamblarea sistemului în această stare.

S4 Non-Volatile Sleep

O stare globală specială de sistem, care permite contextului sistemului să fie salvat si restaurat (relativ lent) atunci când se pierde puterea de la placa de bază. În cazul în care sistemului i-a fost ordonat să intre în starea S4, sistemul de operare va scrie tot contextul sistemului într-un fișier de pe medii de stocare non-volatile și se lasă markeri adecvați contextului. Mașina va intra apoi starea S4. Când sistemul părăsește starea Soft Off sau starea Mechanical Off, trece la starea Working (G0) și repornirea sistemului de operare, o restaurare dintr-un fișier NVS poate să aibă loc. Acest lucru se întâmpla numai dacă un set de date non-volatile speel valid este găsit, anumite aspecte ale configurației mașinii nu s-au schimbat, iar utilizatorul nu a oprit manual restaurarea. Dacă toate aceste condiții sunt îndeplinite, ca parte a repornirii sistemului de operare, acesta va reîncărca contextul sistemului și îl va activa. Efectul net pentru utilizator este ceea ce arata ca o revenire de la o stare de Sleep (G1), dar mai lent. Aspecte ale mașinii care nu trebuie să se schimbe includ, dar nu sunt limitate la, layout-ul pe disc și dimensiunea memoriei. Ar putea fi posibil pentru utilizator schimbarea unui card PC sau un dispozitiv Device Bay.

Se observă că, pentru ca mașina să tranziționeze direct de la Soft Off sau stările de Sleep direct la starea S4, contextul sistemului trebuie să fie scris pe un mediu de stocare hardware non-volatilș intrarea în starea Working prima dată, astfel încât sistemul de operare sau BIOS-ul să poată salva contextul sistemului durează prea mult din punctul de vedere al utilizatorului. Tranziția de la starea Mechanical Off la starea S4 este probabil să se facă atunci când utilizatorul nu este acolo pentru a o vedea.

Deoarece starea S4 se bazează doar pe spații de stocare nonvolatile, o mașină poate salva contextul său pentru o perioadă arbitrară de timp (de ordinea a mai multor ani).

Se observă că mențiunile pentru G2/S5 și G3 din coloana Latency(Latență) din tabelul de mai sus sunt "Long"(Mare). Acest lucru presupune faptul că o platformă destinată pentru a oferi utilizatorului aspectul de "instant-on", similar cu un dispozitiv electrocasnic, va folosi stările G0 și G1 aproape exclusiv (starea G3 poate fi utilizată pentru deplasarea mașinii sau reparatii).

3.2 Stările de putere ale dispozitivelor (Device Power States)

Stările de putere dispozitiv sunt stări de dispozitive speciale, ca atare, acestea nu sunt, în general, vizibile pentru utilizator. De exemplu, unele aparate pot fi în starea Off, chiar dacă sistemul în ansamblu este în stare de lucru.

Stările dispozitiv se aplică la orice aflat pe orice magistrală. Ele sunt, în general, definite în funcție de patru criterii principale:

Consumul de energie. Cât de multă putere folosește aparatul.

Contextul dispozitivului. Cât de mult din contextul dispozitivului este reținut de către hardware-ul. Sistemul de operare este responsabil pentru restabilirea oricărui context dispozitiv pierdut (acest lucru poate fi realizat prin resetarea aparatului).

Driver-ul dispozitivului. Ce trebuie să facă driverul de dispozitiv pentru a restaura dispozitivul în starea maximă de lucru.

Timpul de restaurare. Cât timp este necesar pentru a restabili aparatul la starea maximă de lucru.

Stările de putere dispozitiv sunt definite mai jos, deși foarte generic. Multe dispozitive nu au toate cele patru stări definite. Dispozitivele pot fi capabile de diferite moduri de funcționare în cu consum redus de energie, dar dacă nu există nici o diferență între moduri, numai modul cu cel mai mic consum de putere va fi folosit.

Lista stărilor de putere dispozitiv:

D3 (Oprit)

Alimentarea a fost complet îndepărtată. Contextul dispozitivului este pierdut atunci când se intră în această stare, astfel ca software-ul sistemului de operare va reinițializa dispozitivul atunci când este alimentat din nou. Deoarece contextul dispozitivului și puterea sunt pierdute, dispozitivele din această stare nu decodează liniile lor de adresă. Dispozitivele în această stare au celmai amre timp de restaurare. Toate clasele de dispozitive definesc această stare.

D3 hot

Sensul stării D3hot este definită de fiecare clasă de dispozitive. Dispozitivele în starea D3hot sunt trebuie să fie enumerabile software-ului. În general, în starea D3hot este așteptat a se economisi mai multă putere și, opțional, păstra context dispozitiv. În cazul în care contextul dispozitivul este pierdut atunci când se intră în această stare, software-ul sistemului de operare va reinițializa aparatul atunci când se trece la D0. Dispozitivele în această stare pot avea timpii de resturare cei mai mari. Toate clase de dispozitive definesc această stare.

NOTĂ: Starea D3hot diferă de starea D3 în doi parametri distincți: alimentarea principală este prezentă și software-ul poate accesa un dispozitiv în D3hot. Pentru dispozitivele care acceptă atât D3hot și D3 expuse la OSPM prin _PR3, software-ul dispozitivului / driverul trebuie să presupună întotdeauna că OSPM va viza D3 și trebuie să presupună că contextul dispozitiv se va pierde.

D2

Sensul stării D2 este definită de fiecare clasă de dispozitive. Multe clase dispozitiv nu pot defini D2. În general, în starea D2 este de asteptat mai mult a se salva energie și mai puțin păstrarea contextului dispozitivului decât în D1 sau D0. Magistralele în D2 pot provoca pierderea unor părți din context (de exemplu, prin reducerea alimentării pe magistrale, forțând astfel dispozitivul să oprească o parte din funcțiile sale).

D1

Sensul stării D1 este definit de fiecare clasă de dispozitive. Multe clase dispozitiv nu pot defini D1. În general, în starea D1 este de asteptat mai puțin a se economisi energie și mai mult a se păstra contextul dispozitivului mai mult decât D2.

D0 (Complet-On)

Această stare se presupune a fi corespunzătoare celui mai înalt nivel al consumului de energie. Dispozitivul este complet activ și poate să răspundă, și este de așteptat să-și amintească tot contextul relevant continuu.

Notă: Dispozitivele, de multe ori, au moduri diferite de putere într-o anumită stare. Dispozitive pot utiliza aceste moduri, atât timp cât ele pot comuta automat și transparent între aceste moduri din software, fără a încălca normele de stare actuală Dx în care se află dispozitivul. Modurile de consum redus care afectează negativ performanța sau care nu sunt transparente pentru software nu se pot utiliza în mod automat de către hardware, driverul de dispozitiv trebuie să emită comenzi pentru a utiliza aceste moduri.

Stările de Sleep

Stările de Sleep (Sx state) sunt stări în cadrul stării globale de Sleep, G1.Stările Sx sunt pe scurt definite mai jos:

S1 Sleeping state

Starea S1 este o stare cu latența mică la trezire(wake). În această stare, nu se pierde contextul sistem (CPU sau chip set) și hardware-ul susține tot contextul sistemului.

S2 Sleeping state

Starea S1 este o stare cu latența mică la trezire(wake). Această stare este similară cu starea S1 cu excepția faptului că este pierdut contextul procesorului și sistemul de cache (sistemul de operare este responsabil pentru menținerea contextului cache-ului CPU). Control pornește de la vectorul de reset al procesorului după evenimentul de trezire(wake).

S3 Sleeping state

Statul Starea S1 este o stare cu latența mică la trezire(wake) în care tot contextul sistemului este pierdut, cu excepția memoriei de sistem. CPU, memorie cache, și de contextul chip set-ului se pierd în această stare. Hardware-ul menține contextul memoriei și restabilește o parte a contextului de configurare al CPU-ului și al L2). Control pornește de la vectorul de reset al procesorului după evenimentul de trezire(wake).

S4 Sleeping state

Starea S4 are cea mai mică putere, cea mai lungă latență de trezire(wake) acceptate de ACPI. Pentru a reduce puterea de la un nivel minim, se presupune că platforma hardware a oprit toate dispozitive. Contextul platformei este menținut.

S5 Starea Soft Off

Starea S5 este similară cu starea S4 cu excepția faptului că sistemul de operare nu salvează orice context. Sistemul este în starea "soft off" și necesită o boot-are completă atunci când se trezește. Software-ul utilizează o altă valoare de stare pentru a face distincția între starea S5 și starea S4, pentru a permite operațiunile de încărcare inițială în BIOS pentru a distinge dacă boot-are are loc sau nu dintr-o imagine de memorie salvată.

Stările de consum ale procesorului (Procesor power states)

Stările de consum ale procesorului (Cx states) sunt stări ale consumului de energie al procesor și de management al căldurii în cadrul stării globale Working, G0. Stările Cx dispun de semantică de intrare și de ieșire specifice și sunt definite pe scurt de mai jos:

C0 Procesor power state

În timp ce procesorul este în această stare, se execută instrucțiunile.

C1 Procesor power state

Această stare de putere are cea mai mică latență. Latența hardware în acest stat trebuie să fie suficient de scăzută încât software-ul de operare să nu ia în considerare aspectul stării de latență atunci când se decide să folosească această stare. În afară de punerea procesor într-o stare de non-executare, această stare nu are nici un alt efect vizibil in cadrul software-ului.

C2 Procesor power state

Starea C2 oferă imbunătățiri în economia consumului față de starea C1. Cel mai rău caz de latență hardware pentru această stare este oferit prin intermediul firmware-ul sistemului ACPI și software-ul de operare poate folosi aceste informații pentru a determina cazul în care starea C1 ar trebui să fie folosită în loc de starea C2. În afară de punerea procesor într-o stare de non-executare, această stare nu are nici un alt efect vizibil in cadrul software-ului.

C3 Procesor power state

Starea C3 oferă în economia consumului față de stările C1 și C2. Cel mai rău caz de latență hardware pentru această stare este oferit prin intermediul firmware-ul sistemului ACPI și software-ul de operare poate folosi aceste informații pentru a determina cazul în care starea C2 ar trebui să fie folosită în loc de starea C3. În timp ce procesorul e în starea C3, cache-ul acestuia iși menține starea, dar ignora orice investigații. Software-ul de operare este responsabil pentru asigurarea menținerii coerente a cache-ului

Stările de performanță ale procesorului si dispozitivelor (Device and Processor Performance States)

Stările de performanță ale procesorului si dispozitivelor (Px states) sunt stări de consum de energie și de capabilități în cadrul stărilor activă / de execuție, C0 pentru procesoare și D0 pentru dispozitive. Stările Px sunt definite pe scurt mai jos:

P0 Performance State

În timp ce un dispozitiv sau procesor este în această stare, se folosește capacitatea sa de performanță maximă și poate consuma puterea maximă.

P1 Performance State

În această stare de performanță, capacitatea de performanță a unui dispozitiv sau procesor este limitată mai jos de valoarea maximă și consumă mai puțină putere decât puterea maximă posibilă.

Pn Performance State

În această stare de performanță, capacitatea de performanță a unui dispozitiv sau procesor este la nivelul minim și consumă minim rămânând în același timp într-o stare activă. Starea n este un număr maxim și este dependent de procesor sau de dispozitiv. Procesoarele și dispozitivele pot defini suport pentru un număr arbitrar de stări de performanță care nu trebuie să depășească 16.

System Power management

Sub OSPM, sistemul de operare direcționează toate tranzițiile stărilor de sistem și dispozitiv. Preferințele utilizatorului și cunoștințele modul de folosire al dispozitivelor sunt utilizate de aplicații, sistemul de operare punând sau scoțând dispozitivele din stări de consum redus. Dispozitivele care nu sunt utilizate pot fi dezactivate. În mod similar, sistemul de operare folosește informații de la aplicații și setări de utilizator pentru a pune întreg sistemul într-o stare de consum redus. Sistemul de operare foloseste ACPI pentru a controla tranzițiile de consum în hardware.

Din punctul de vedere al utilizatorului, sistemul poate fi vazut ca aflându-se într-una din stările prezentate în urmatoarea diagramă.

Consumul de energie în microprocesor

Circuitele CMOS, folosite în majoritatea microprocesoarelor, au atât consum static cât și consum dinamic de energie. Consumul static este cauzat de părtinire și curenții de scurgere, dar este nesemnificativ în cele mai multe proiectări care consuma mai mult de 1 mW.

Consumul dominant de putere pentru microprocesoarele CMOS este componenta dinamică. Fiecare tranziție a unui circuit digital consumă energie, deoarece fiecare încărcare și descărcare a capacității circuitului digital consumă energie.Consumul de energie dinamic este egal cu

Unde:

M este numărul de porți din circuit

este capacitatea porții k

este frecvența de schimbare a porții k

este tensiunea de alimentare

Se observă că reducerea tensiunii de alimentare este modalitatea cea mai eficientă de a reduce consumul de energie. Prin scăderea tensiunii de alimentare apare problema creșterii timpului de răspuns a circuitelor. O estimare a latenței circuitelor e dată de formula:

Unde:

T este propagarea întârzierii tranziției CMOS

este tensiunea de prag

este tensiunea de intrare

Propagarea întârzierii restricționează frecvența de lucru a microprocesorului. Din cele două ecuații se poate observa ca există un compromis între schimbarea frecvenței și a tensiunii de alimentare. Procesoarele pot opera la o tensiune de alimentare mai scăzută, dar numai dacă frecvența de lcru e scăzută astfel încât să tolereze creșterea timpului de propagare a întârzierii.

Presupunem că puterea dinamică este cea dominantă și că porțile k ale microprocesorului formează o capacitate colectivă cu o frecvență comună de comutare f, obținem formula:

Formula arată că scăderea frecvenței reduce consumul de energie liniar și scăderea tensiunii de alimentare reduce consumul de nergie în mod pătratic.

Calea critică într-un procesor este cea mai lungă cale pe care un semnal trebuie să o străbată. Constrângerea implicită este că timpul de propagare al întârzierii să fie mai mic decât . De fapt, procesorul nu mai funcționează când tensiunea de alimentare este scăzută și timpul de propagare al întârzierii este prea mare să satisfacă timpii interni determinați de frecvența f.

Dynamic voltage scaling

Scalarea de tensiune dinamică este o tehnică de gestionare a puterii în arhitectura calculatoarelor, în care tensiunea utilizată într-o componentă este crescut sau scăzut, în funcție de circumstanțe. Scalarea dinamică de tensiune pentru a crește tensiunea este cunoscută sub numele de overvolting; scalarea dnamică a tensiunii pentru a reduce tensiunea este cunoscută sub numele de undervolting. Undervolting se face în scopul de a economisi energie, în special în laptop-uri și alte dispozitive mobile, în cazul în care energia vine de la o baterie și, astfel, este limitată. Overvolting se face în scopul de a creste performanța calculatorului, sau, în cazuri rare, pentru a crește fiabilitatea.

Multe componente moderne permit reglarea tensiunii să fie controlată prin intermediul software-ului (de exemplu, prin intermediul BIOS-ul). Este de obicei posibil să fie controlate tensiunile de alimentare ale CPU, RAM, PCI, PCI Express (sau AGP), prin BIOS-ul PC-ului.

Cu toate acestea, unele componente nu permit software-ului să aibă controlul tensiunilor de alimentare, și modificarea hardware-ului este necesară pentru a face overvolting (overclocking). Plăcile video si placa de bază sunt componente care de obicei necesită modificări hardware pentru a schimba tensiuni de alimentare.

Undervolting este termenul utilizat atunci când tensiunea unei componente, de obicei, procesor, este redusă pentru a crește stabilitatea și/sau a reduce temperatura. Acest lucru poate fi de dorit în calculatoare răcite pasiv, de exemplu, cum ar fi un Home Theater PC, în care zgomotul ventilatorului poate fi nedorit.

Dynamic Frequency Scaling

Scalarea dinamică a frecvenței (de asemenea, cunoscută sub numele de CPU throttling) este o tehnică în arhitectura calculatoarelor prin care frecvența unui microprocesor poate fi ajustată automat "on the fly", fie pentru a conserva energia sau pentru a reduce cantitatea de căldura generată de cip. Scalarea frecvenței dinamică este frecvent utilizată în laptop-uri și alte dispozitive mobile, în cazul în care energia vine de la o baterie și, astfel, este limitată. De asemenea, este utilizată în setările de quiet computing și să diminueze costurile de energie și de răcire pentru mașini puțin încărcate. Mai puțină căldură disipată, la rândul său, permite venilatoarelor sistemulelor de răcire să fie încetinite sau oprite, reducând nivelele de zgomot și consumul de energie și mai mult. De asemenea, este utilizată pentru reducerea căldurii în sistemele insuficient răcite în cazul în care temperatura atinge un anumit prag, cum ar fi în sistemele overclockate dar prost răcite.

Scalarea dinamică a frecvenței reduce numărul de instrucțiuni pe care procesor poate să le emite într-o anumită perioadă de timp, reducându-se astfel performanța. Prin urmare, este în general utilizată atunci când volumul de muncă nu este legat de CPU.

Atât scalarea dinamică de tensiune cât și scalaredinamică a frecvenței pot fi utilizate pentru a preveni supraîncălzirea sistemului de calcul, ceea ce poate duce la oprirea unui program sau a sistemului de operare, și, eventual, să defecteze hardware-ul. Reducerea tensiunii de alimentare a procesorului mai jos de setarea minimă recomandată de către producător poate duce la instabilitatea sistemului.

Tehnologii care utilizeză Dynamic Voltage Scaling și Dynamic Frequency Scaling sunt SpeedStep, în procesoarele Intel; AMD dezvoltă două astfel de tehnologii: AMD’s Cool’n’Quiet, folosită la procesoarele destiante desktopurilor si serverelor, în care scopul nu e lungirea vieții bateriei ci disiparea de cât mai puțină căldură, care permite ventiatoarelor de sistem să iși reducă viteza, obținând un mediu de lucru mai rece și mai silențios. Tehnologia AMD’s PowerNow! E folosită în sisteme mobile dar și în unele desktopuri.

4.3 SpeedStep

SpeedStep este o marcă comercială pentru o serie de tehnologii de scalare dinamică a frecvenței (nume de cod Geyserville și inclusiv SpeedStep, SpeedStep II, și SpeedStep III), construite în unele microprocesoare Intel, care permite ca frecvența procesorului să fie schimbată dinamic (între diferite P-states), prin intermediul software-ului. Acest lucru permite procesorului să satisfacă nevoile instantanee de performanță a operațiunilor efectuate, minimizând în același timp consumul de putere și disiparea căldurii. Enhanced Intel SpeedStep este uneori abreviată ca EIST.

Enhanced Intel SpeedStep Technology a revoluționat managementul termic și de consum prin acordarea aplicațiilor software a unui control mai mare asupra frecvenței procesorului și asupra tensiunei de alimentare. Sistemele pot gestiona cu ușurință consumul de energie dinamic.

Sistemele integrate de astăzi cer o performanță mai mare la niveluri echivalente ale consumului de energie. Suporult hardware pentru Legacy backplane, dimensiunile plăcilor și soluții termice au forțat echipele de design pentru a pună un accent mai mare pe bugetele destinate energiei termică și a consumului. Intel a extins inovații arhitecturale pentru economisirea energiei prin punerea în aplicare a noi caracteristici cum ar fi tehnologia Enhanced Intel SpeedStep.

Tehnologie Enhanced Intel SpeedStep permite ca performanța procesorului și nivelurile de consum de putere să fie modificate în timp ce un sistem funcționează. Acest lucru este realizat prin intermediul software-ului de aplicație, care se schimbă frecvența raportului magistrală-nucleu și tensiunea procesorului (Vcc). O varietate de intrări, cum ar fi sursă de energie a sistemului, starea termică a procesorului, sau politica sistemului de operare sunt utilizate pentru a determina cea mai bună stare de funcționare.

Modelul software-ul din spatele Tehnologie Enhanced Intel SpeedStep are controlul final asupra tranzițiilor frecvenței și tensiunii. Acest model software este un important pas înainte față de implementările anterioare ale tehnologiei Intel SpeedStep. Versiuni mai vechi ale tehnologiei Intel SpeedStep aveau nevoie de suport hardware prin chipset. Tehnologia Enhanced Intel SpeedStep a eliminat cerința hardware a chipset-ului și necesită doar sprijinul sistemului regulator de tensiune, al procesorului și al sistemului de operare. Centralizarea mecanismului de control și interfețelor software pentru procesor, și reducerea timpului de lucru a hardware-ului a redus timpul de indisponibilitate al procesorului până la 10 μs față de generația anterioară unde era de 250 μs.

Versiunile mai vechi de Microsoft Windows, Windows 2000 și mai devreme, au nevoie de un driver special și o aplicație specială pentru a accesa caracteristica SpeedStep. Site-ul Intel precizează că astfel de drivere trebuie să provină de la producătorul computerului;. Nu există drivere generice furnizate de Intel, care să permită utilizarea SpeedStep pentru versiunile mai vechi Windows dacă nu se poate obține un driver de la producător.

Microsoft Windows XP suporăt SpeedStep, tehnologia fiind inclusă în consola de power amangement sub panoul de control(Control Panel). În Windows XP, un utilizator poate regla viteza procesorului indirect, prin schimbarea scheme de alimentare : "Home / Office Desk" dezactivează SpeedStep, "Portable / Laptop" SpeedStep e acivat, și "Max baterie" foloseste SpeedStep pentru a incetini procesorul la niveluri de putere minimă pe măsuă ce bateria slăbește. Setările SpeedStep pentru scheme de alimentare, fie built-in sau particularizate, nu pot fi modificate din panoul de control, dar pot fi modificate folosind comanda POWERCFG.EXE din linie de comandă.

Linux are suport deplin SpeedStep integrat în versiunea de kernel 2.6.

Mac OS are, de asemenea, SpeedStep inclus în nucleu, de la lansarea versiunii Intel a Mac OS X 10.4 și este deja activat. Nu poate fi controlat în Preferințe sistem "Energy Saver." Pentru a dezactiva această caracteristică, și a stabilit o frecvență specifică (viteza maximă sau redusă) necesită o cerere de terță parte, cum ar fi coolbook.

Solaris a suportă SpeedStep din OpenSolaris SXDE 9 / 07.

Nucleele BSD susțin pe deplin integrarea SpeedStep.

Versiuni de Intel SpeedStep:

V1.1 este utilizat de a doua generatie de procesoare Pentium III. Acesta permite procesorului să comute între două moduri: de frecvență înaltă și joasă. Acest lucru se realizează prin modificarea multiplicatorului CPU. Un procesor la 1 GHz Pentium III consumă aproximativ 20 wați ar putea fi redus la 600 MHz, ceea ce reduce consumul de energie la aproximativ 6 wați.

V2.1 (Enhanced SpeedStep) este utilizată în Pentium III-Mobile procesoare și este similar cu versiunea anterioară, dar în modul de joasă frecvență procesorul utilizează, de asemenea, o tensiune diferită de modul de frecvență înaltă.

V2.2 este adaptat pentru procesoare Pentium 4-Mobile. Cu aceasta, de 1,8 GHz Pentium 4-M consuma aproximativ 30 de wați, iar la o joasă frecvență de 1,2 GHz, reducând astfel consumul de energie la aproximativ 20 de wați.

V3.1 (EIST) este folosit cu prima generație și a doua procesoare Pentium M (nuclee Banias și nuclee Dothan, utilizate în platforme Centrino). Cu această tehnologie, procesorul variază frecvența (și tensiunea) între aproximativ 40% și 100% din frecvența de bază ale sale în incremente de 100 MHz (pentru Banias) sau MHz 133 (pentru Dotan). Cu această tehnologie, Intel introduce, de asemenea in timp real de nivel 2 de variație a capacității de memorie cache, îmbunătățind și mai mult economiei de energie.

V3.2 (Enhanced EIST) este adaptată pentru procesoare multi-core, cu unificate cache de nivel 2.

Modurile de sus și de jos sunt de obicei cunoscute sub numele de modul de frecvență înaltă (HFM) și modul de frecvență joasă (LFM). Aceste puncte de frecvența și tensiunea de operare sunt stocate într-un registru specific procesorului ce poate fi doar citit (MSR – Model Specific Register). Acest MSR asigură faptul că BIOS-ul nu va permite tranziția către stări invalide mai sus decât HFM maximă sau sub nivelul minim LFM. Celelalte patru puncte de operare sunt stocate în cod BIOS, ca un tabel cu căderi de tensiune furnizat de Intel la furnizorii de BIOS.

Suportul nativ în Windows XP și Windows Server 2003 constă din două componente:

managerul politicii de consum al kernel-ului și driver-ul procesor.

Managerul politicii de consum al kernel-ului deține luarea deciziilor, precum și setul de reguli utilizate pentru a determina starea de funcționare potrivită pentru frecvența/tensiune. Poate lua decizii bazate pe mai multe intrări, cum ar fi politica de consum a utilizatorul final, utilizarea procesorului, nivelul bateriei, sau condiții termice și evenimente. Driver-ul procesorului este folosit pentru a face tranziții reale între stări în numele managerul politicii de consum al kernel-ului. Driverul nu inițiază tranziții de stări frecvență/tensiune independent de managerul politicii de consum al kernel-ului.

Modelul software pentru Windows XP și Windows Sever 2003 este prezentat în figura urmataore:

Politica deconsm finală este introdusă prin intermediul icoanei "Power Options" din Panoul de control. Bazându-se pe politica selectată, Windows va ajusta luarea deciziilor pentru stările de onsum în consecință.

Politica de control dinamic a procesorului a fost definită ca procesorul să funcționeze în unu din cele patru stări: None, Adaptive, Constant, și Degrade. "None" va asigura că procesorul este intotdeauna în cea mai înaltă stare de performanță disponibilă la momentul respectiv, restricționând orice condiții unice termice în cazul în care hardware-ul va forța setarea unei stări mai mici de consum.

"Adaptive" coincide cu starea de performanță la cererea actuală. "Constant" va rula procesorul în cea mai de jos stare frecvență/tensiune disponibilă. Ca și în starea constantă, "Degrade" va rula întotdeauna în cel mai mică stare frecvență/tensiune disponibile. În plus, această politică de stare va utiliza un mecanism liniar de reglare consumului în cazul în care capacitatea rămasă a bateriei scade sub un anumit prag.

Arhitectura driverelor Windows

Figura 3-1 este o diagrama foarte prescurtată a funcționalității sistemului de operare Windows XP. Fiecare platformă pe care se rulează Windows XP suportă două moduri de execuție. Software-ul execută fie în modul utilizator sau în modul kernel. Un program utilizator, care vrea să citească unele date de la un dispozitiv ar numi o interfață de programare a aplicației (API), cum ar fi ReadFile. Un modul subsistem, cum ar fi Kernel32.dll implementează această interfață prin invocarea unei funcții native API, cum ar fi NtReadFile.

Se spune că NtReadFile face parte dintr-o componentă de sistem numită Manager I/O. Termenul I/O Manager se referă la o colecție de servicii ale sistemului de operare, care înconjoară un driver.

Multe rutine servesc un scop similar cu NtReadFile. Acestea funcționează în modul kernel, în scopul de a solicita o cerere a unei aplicații de a interacționa cu un dispozitiv într-un anumit mod. Acestea validează toți parametrii, asigurându-se astfel că nu permit din greșeală o încălcare a securității prin efectuarea unei operație, sau accesarea unor date, pe care programul în mod utilizator nu ar fi fost capabil să aibă de acces la ele. Rutinele crează o structură de date numit un pachet de cerere I/O (IRP I/O Request Package), pe care îl dăa mai departe unui punct de intrare în unele drivere de dispozitiv. În cazul unui apel ReadFile, NtReadFile ar crea un IRP cu codul major de funcție (Major Function Code) IRP_MJ_READ (o constantă într-un fișier antet al DDK). Detaliile de prelucrare în acest punct poate diferi, dar un scenariu probabil este ca o rutina cum ar fi NtReadFile să revină la apelantului din mod utilizator, indicând faptul că operațiunea descrisă de IRP nu s-a terminat încă. Programul în mod utilizator ar putea să iși continua activitatea și apoi să aștepte ca operațiunea să se termine, sau ar putea aștepta imediat. Oricum, driverul de dispozitiv continuă independent de aplicașie pentru a satisface cererea.

O modalitate utilă de a vedea un driver complet este ca un pachet pentru o colecție de subrutine pe care sistemul de operare le solicită pentru a efectua diverse operații care au legătură cu componente hardware. Figura 3.2 ilustrează acest concept. Unele rutine, cum ar fi DriverEntry și AddDevice, precum și funcții de dispatch pentru câteva tipuri de IRP trebuie să fie prezente în orice driver. Drivere care au nevoie să adauge mai multe cereri ar putea conține și rutina StartIo. Drivere care au transferuri cu acces direct la memorie (DMA) vor avea o rutină AdapterControl. Drivere pentru dispozitive care generează întreruperi hardware vor avea o rutina de tratare a întreruperii (ISR – Interrupt Service Routine) și o rutină deferred procedure call (DPC). Majoritatea driverelor au funcții de tratare pentru mai multe tipuri de IRP pe lângă cele trei care sunt prezentate în Figura 3.2.

Un driver este și el un fișier executabil. Are extensia .SYS, iar structural, fișierul pe disc arată ca orice altă aplicație Windows. Ca și alte aplicații, driverele folosesc rutine ajutătoare, multe dintre ele fiind legate dinamic de către nucleul sistemului de operare sau de către un driver de clasă sau altă bibliotecă cu rol de suport.

Diferit de aplicații, un driver nu conține un program principal, ci conține o colecție de subrutine pe care sistemul poate să le apeleze când consideră că este necesar.

Structura unui IRP

MdlAddress (PMDL) este adresa unei liste descriptor de memorie ( memory descriptor list – MDL), care descrie bufferul din mod utilizator asociat cu aceasta cerere. Managerul de I/O creează această listă pentru cererile IRP_MJ_READ și IRP_MJ_WRITE dacă steagurile obiectul cel mai de sus al dispozitivului indică DO_DIRECT_IO. Se creează o listă pentru bufferul de ieșire utilizat cu o solicitare IRP_MJ_DEVICE_CONTROL în cazul în care codul de control indică METHOD_IN_DIRECT sau METHOD_OUT_DIRECT. Lista în sine descrie bufferul virtual al modului utilizator și conține de asemenea adresele fizice ale paginilor blocate care conțin acel buffer. Un driver trebuie să facă eforturi suplimentare, care pot fi minime, pentru a accesa buffer-ul modului utilizator.

Flags (ULONG) conține opțiuni pe care un driver de dispozitiv le poate citi, dar nu le modifica în mod direct. Nici unul dintre acești indicatori nu sunt relevanți pentru un driver Windows Driver Model (WDM).

AssociatedIrp (union) este o uniune a trei pointeri posibili. Alternativa pe care un driver WDM tipic ar dori să o acceseze este numită AssociatedIrp.SystemBuffer. Pointerul bufferului de sistem deține adresa unui buffer de date nepaginate în memoria kernel. Pentru operațiunile IRP_MJ_READ și IRP_MJ_WRITE, Managerul I/O creează acest bufferul de date dacă steagurile obiectul cel mai de sus al dispozitivului specifica DO_BUFFERED_IO. Pentru operațiunile IRP_MJ_DEVICE_CONTROL, Managerul I/O creează această buffer în cazul în care codul funcției de control I/O indică faptul că ar trebui. Managerul I/O copiază date trimise de codul utilizator în acest buffer ca parte a procesului de creare a IRP. Aceste date includ datele necesare unui apel WriteFile sau așa-numitele date de intrare pentru un apel la DeviceIoControl. Pentru cereri de citire, driverul de dispozitiv umple acest buffer cu date; Managerul I/O copiază mai târziu bufferul înapoi în bufferul utilizator. Pentru operațiunile de control care specifica METHOD_BUFFERED, driverul pune datele de ieșire în acest buffer, și managerul I/O îl copiază in buffer de ieșire utilizator.

IoStatus (IO_STATUS_BLOCK) este o structură care conține două câmpuri pe care driverele pe setează, atunci când în cele din urmă se termină o cerere. IoStatus.Status va primi un cod de NTSTATUS, în timp ce IoStatus.Information este un ULONG_PTR care va primi o valoare informațională a căror conținut depinde de tipul IRP-ului și statutul de finalizare. O utilizare comună a câmpului de informare este de a menține numărul total de octeți transferați printr-o operație, cum ar fi IRP_MJ_READ, care transferă date. Anumite cereci Plug and Play (PnP) utilizează acest câmp ca un pointer la o structură care poate fi văzută ca răspuns la o cerere.

RequestorMode va fi egal cu una dintre constantele enumerate UserMode sau KernelMode, in funcție de originea de unde s-a primit cererea de I/O. Driverele verifică uneori această valoarepentru a ști dacă să aibă încredere în unii parametri.

PendingReturned (Boolean) este semnificativă într-o rutină de finalizare și indică dacă rutina următoare de dispatch a întors STATUS_PENDING.

Cancel (Boolean) este TRUE dacă IoCancelIrp a fost chemat pentru a anula această cerere și FALSE în cazul în care nu a fost (încă) chemat.

CancelIrql (KIRQL) este nivelul cererii de întrerupere (interrupt request level – IRQL), la care s-a facut cererea de anulare.

CancelRoutine (PDRIVER_CANCEL) este adresa unei rutine de anulare a IRP în driver. Se utilizează IoSetCancelRoutine pentru a seta acest câmp în loc de a-l modifica în mod direct.

UserBuffer (PVOID) conține adresa virtuală a modului utilizator a buffer-ului de ieșire pentru o cerere IRP_MJ_DEVICE_CONTROL pentru care codul de control precizează METHOD_NEITHER. El conține, de asemenea, adresa virtuală a modului utilizator a buffer-ului pentru cereri de citire și scriere, dar un driver ar trebui să specifice, de obicei, unul dintre steagurile de dispozitiv DO_BUFFERED_IO sau DO_DIRECT_IO și nu ar trebui, prin urmare, să acceseze câmpul pentru citiri sau scrieri. Atunci când se manipulează o operațiune de control METHOD_NEITHER, driverul poate crea propriul listă MDL utilizeând această adresă.

Tail.Overlay este o structură în cadrul unei uniuni care conține mai mulți membri potențial utili pentru un driver WDM. În figura 3.4, elementele la același nivel citind de la stânga la dreapta sunt alternative într-o uniune, în timp ce dimensiunea verticală portretizează locații succesive în cadrul unei structuri. Tail.Overlay.DeviceQueueEntry (KDEVICE_QUEUE_ENTRY) și Tail.Overlay.DriverContext (PVOID [4]) sunt alternative în cadrul unei uniuni anonime din Tail.Overlay. Managerul de I/O utilizează DeviceQueueEntry ca un câmp de legătură în cadrul standard al cozii de cereri pentru un dispozitiv. Rutinele de anulare în siguranță IoCsqXxx utilizează ultima intrare în vectorul DriverContext.

5.2 Stiva I/O

Ori de câte ori un program de ce rulează în mod kernel creează un PIR, se creează de asemenea o serie de structuri asociate IO_STACK_LOCATION: o singură locație de stivă pentru fiecare dintre driverele care vor procesa IRP-ul și uneori încă o locație de stivă pentru originea IRP-ului. O locație de stivă conține codurile de tipuri și informații parametru pentru IRP-uri, precum și adresa unei rutine de finalizare.

5.2.1 Structura de date a unei locații de stivă I/O:

MajorFunction (UCHAR) este codul funcției majore asociate cu acest IRP. Acest cod este o valoare, cum ar fi IRP_MJ_READ care corespunde unuia dintre pointerii funcțiilor de dispatch din tabelul MajorFunction a unui obiect driver.

MinorFunction (UCHAR) este un cod al funcției minore care identifică în continuare un IRP care aparține unei clase de câteva funcții majore. Cereri IRP_MJ_PNP, de exemplu, sunt împărțite într-o duzină de subtipuri cu coduri de funcții minore, cum ar fi IRP_MN_START_DEVICE, IRP_MN_REMOVE_DEVICE, și așa mai departe.

Parameters (union) este o uniune de substructuri, câte una pentru fiecare tip de cerere, care are anumiți parametri. Substructuri includ, de exemplu, Create (pentru cererile IRP_MJ_CREATE), Read (pentru cereri IRP_MJ_READ), și StartDevice (pentru subtip IRP_MN_START_DEVICE de IRP_MJ_PNP).

DeviceObject (PDEVICE_OBJECT) este adresa obiectului dispozitiv care corespunde acestei intrări în stivă. IoCallDriver completează acest câmp

FileObject (PFILE_OBJECT) este adresa obiectului fișierului kernel-ului spre care IRP-ul este îndreptată. Driverele folosesc adesea indicatorul FileObject de a corela IRP-urile într-o coadă, cu o cerere (sub forma unui IRP_MJ_CLEANUP) de a anula toate IRP-urile din coadă în curs de pregătire pentru închiderea obiectului fișier.

CompletionRoutine (PIO_COMPLETION_ROUTINE) este adresa unei rutini de finalizare I/O, instalată de către driverul de mai sus față de cel căruia corespunde locașia curentă din stivă. Nu se setează acest câmp direct,ci se apelează IoSetCompletionRoutine, care stie sa se refere la locația stiva de mai jos. Driverul de la nivelul cel mai mic în ierarhia de drivere pentru un anumit dispozitiv nu are nevoie de o rutina de completare, pentru că trebuie să completeze cererea. Driverul orgine al cererii are uneori nevoie de o rutină de finalizare, dar nu are, de obicei, locația sa proprie de stivă. De aceea, fiecare nivel din ierarhie utilizează următoarea locație mai mică de stivă pentru a deține propriul pointer al rutinei de finalizare.

Context (PVOID) este o valoare context arbitrară, care va fi trecută ca un argument la rutina de finalizare. Nu se setează acest câmp direct; este setat automat de unul dintre argumentele pentru IoSetCompletionRoutine.

Tranzițiile stărilor de consum

Sistemul se inițializează în starea Working. Acest lucru este de la sine deoarece computerul este, prin definiție, în starea de lucru ori de câte ori execută instrucțiuni. Majoritatea dispozitivelor încep în starea D0, deși proprietarul politicii pentru dispozitiv poate să îl pună într-o stare de consum mai redusă atunci când nu este folosit. După ce sistemul este funcțional, se ajunge la o stare de echilibru în care nivelul de consum al sistemului este de lucru și dispozitivele sunt în stări diferite, în funcție de activitate și capabilități

Acțiunilor utilizatorului final și evenimente externe ulterioare pot cauza tranziții între stările de consum. Un scenariu de tranziție comun apare atunci când utilizatorul foloseste comanda Stand By pentru a pune calculatorul în modul standby. Ca răspuns, Power Managerul solicită prima dată fiecărui driver dacă perspectiva pierderii alimentării va fi OK prin trimiterea unei cereri IRP_MJ_POWER cu codul minor IRP_MN_QUERY_POWER. Dacă toate driverele consimt, Power Managerul va trimite un al doilea IRP cu codul funcției minore IRP_MN_SET_POWER. Driverele pun dispozitivele lor în stări de comsun mai mici, ca răspuns la acest al doilea IRP. În cazul în care un driver respinge cererea, Power Managerul trimite încă o cerere IRP_MN_SET_POWER, dar se specifică, de obicei, la nivelul actual de putere în loc de cea propusă inițial.

Sistemul nu trimite întotdeauna cereri IRP_MN_QUERY_POWER. Unele evenimente (cum ar fi utilizatorul deconectează calculatorul sau expiră bateria) trebuie să fie acceptată fără ezitare, și sistemul de operare nu va emite o interogare atunci când ele apar. Dar atunci când o interogare este emisă, și atunci când un driver acceptă schimbarea de stare propusă de cerere, driverul se angajează că nu va începe orice operațiune care ar putea interfera cu setarea stării de consum așteptate. Un driver de bandă, de exemplu, se va asigura că nu retensionează banda, întreruperea retensionării putând rupe banda, înainte de a permite unei interogări pentru o stare de consum redus de a fin completată. În plus, driverul va respinge orice comanda de retensionare ulterioară până când (și dacă) o cerere contrară de setare a stării de consum semnalează abandonarea schimbării stării de consum.

Un driverul functie are două etape de trecere a IRP în jos și efectuarea acțiunilor sale specifice de dispozitiv într-o ordine bine conturată: Când se trece într-o stare de consum mai redusă, se efectuează pașii dependenși de dispozitiv și apoi se transmite cererea mai jos în stiva I/O. La trecerea într-o stare de consum mai mare, driverul transmite cererea în jos în stiva I/O și apoi efectuează pașii dependenși de dispozitiv într-o rutină de finalizare. Acest comportament asigură alimentarea căii ce duce la hardware în timp ce driverul manipulează hardware-ul.

Proiectarea aplicației

Se dorește a se implementa un driver ce monitorizează schimbările stărilor de performanță ale unui procesor din gama Intel utilizând tehnologia Enhanced Intel SpeedStep Technology, abreviată EIST.

7.1 Design

Pentru a putea folosi EIST, driverul trebuie să aibă acces la regiștri specifici modelului procesorului (MSR), iar aceasta se poate realiza doar dacă driverul rulează în mod kernel, nu în mod utilizator.

Ca orice driver, trebuie să fie incluse anumite subrutine, și anume:

DriverEntry: este prima rutină apelată după ce un driver a fost încărcat și este responsabilă cu inițializarea driverului.

AddDevice: rutina este responsabilă pentru crearea unor obiecte funcționale dispozitiv (FDO) sau obiecte filtrul de dispozitiv (filtru DO) pentru dispozitive enumerate de managerul Plug and Play (PnP). Principalele responsabilități sunt apelarea rutinelor IoCreateDevice pentru a crea un obiect dispozitiv și IoAttachDeviceToDeviceStack pentru a atașa obiectul dispozitiv de stiva dispozitivelor.

DriverUnload: rutina execută operațiile care sunt necesare înainte ca sistemul să descarce driverul.

DispatchPnP: rutina oferă suport pentru Plug and Play.

DispatchPower: rutina oferă suport pentru power management. În această rutină toate driverele trebuie să trateze IRP-ul dacă e posibil, să transmită IRP-ul următorului driver din stiva dispozitivelor folosind rutina PoCallDriver, dacă e un driver de magistrală, trebuie să efectueze operația cerută de IRP asupa dispozitivului și să finalizeze cererea.

DriverDispatch: are rol în transportul IRP-urilor.

Driverul nu necesită o rutină de terminare a cererii fiind un driver de sistem.

Pe langă acestea, driverul trebuie să mai conțină rutine de citire și scriere din/în regiștrii MSR și de creare a unor date de ieșire ce pot fi citite de către utilizator.

Implementare

Procesoarele Intel mai noi de generația Pentium M au implementat suport pentru Enhanced Intel SpeedStep Technology. Acest fapt se poate verifica prin citirea bitului 7 din componenta ECX a registrului CPUID.

Pentru funcția de citire a identidății procesorului și funcția de citire a regiștrilor MSB a fost nevoie de o integrare în codul C a unor blocuri de cod assembly, limbaj care conține funcțiile necesare.

Funcția de identiifcare a procesorului:

__int64 my_cpuid(const int InfoType)

{

int CPUInfoHi;

int CPUInfoLo;

__int64 CPUInfo;

__asm

{

mov eax, InfoType

cpuid

mov CPUInfoLo, ecx

mov CPUInfoHi, edx

}

CPUInfo = CPUInfoHi;

CPUInfo = (CPUInfo << 16) | (CPUInfoLo);

return CPUInfo;

}

Activarea EIST se poate face prin setarea bitului 16 în registrul MSR IA32_MISC_ENABLE. Acest bit ar trebui să fie scris de către BIOS la pornirea sistemului.

Tranzițiile între diferitele stări de performanță (perechi frecvență-tensiune) se fac practic prin scrierea unei valori pe 16 biți în registrul IA32_PERF_CTL. Dacă o tranziție este deja în curs de desfășurare când se dorețte o nouă tranziție, a doua tranziție se va fae după încheierea primei tranziții. Citiri ale registrului IA32_PERF_CTL vor returna ultima stare înscrisă. Starea curentă a procesorului se citește din registrul IA32_PERF_STS, care își improspătează conținutul în mod dinamic.

Valoarea pe 16 biți ce codează puncte de lucru valide sunt specifice fiecărui model.

Structura bitilor 15-0 din registrii de stare și control:

15 : Dynamic FSB – numit și Super Low Frequency Mode (SLFM), practic împarte frecvența de operare la jumătate.

14 : Non-integer bus ratio: e ceea ce e numit comun ca multiplicator. Frecvența de operare a procesorului se obține multiplicând frecvența de Front Side Bus(FSB).

13 : Rezervat

11-8 : Identificatrul frecvrnței (FID)

7-6 : Rezervat

5-0 : Identificatorul tensiunii (VID)

Formula de calcul a tensiunii este :

Unde

Vcc este tensiunea sistemului

Vstep este pasul de modificare al tensiunii

Vid0 este tensiunea minimă suportată de sistem. Pentru valori sub această valoare, sistemul nu poate funcționa.

Formula de calcul a frcvenței este :

F =FID * FSB

Pentru citirea registrului de status IA32_PERF_STS funcția este :

__int64 my_readmsr(const int reg)

{

__int64 retval;

int retHi;

int retLo;

/* The value in ECX specifies one of the 64-bit Model-Specific Registers of

the Pentium processor. The content of that Model-Specific Register is

copied into EDX:EAX. EDX is loaded with the high-order 32 bits, and EAX

is loaded with the low-order 32 bits.*/

__asm

{

mov ecx, reg

rdmsr

mov retHi, edx

mov retLo, eax

}

retval = retHi;

retval = (retval << 32) | retLo;

return retval;

}

Pentru screrea în registrul de control IA32_PERF_CTL funcția este:

void my_writemsr(const unsigned long registru, const unsigned long long value)

{

/* The value in ECX specifies one of the 64-bit Model-Specific Registers of

the Pentium processor. The content of EDX:EAX is copied to that Model-

Specific Register. The high-order 32 bits are copied from EDX, and the

low-order 32 bits are copied from EAX. */

int lo = (int)value & 0xFFFF;

int hi = (int)(value >> 32) & 0xFFFF;

__asm

{

mov eax, lo

mov edx, hi

mov ecx, registru

wrmsr

}

}

Funcționalitățile driverului:

La încărcarea driverului, se verifică daca EIST este suportată. În caz negativ , driverul nu execută nimic, iar pachetele IRP de tip IRP_MJ_POWER sunt doar transmise driverului inferior.

Daca EIST e suportată, se verifică daca tehnologia este activată, iar în caz contrar o activează prin scrierea registrului IA32_MISC_ENABLE, după care se verifică din nou daca tehnologia s-a activat.

Fiecare modificare a stării de performanță se notează într-un fișier numit ‘testdriver.txt’ care se află pe partiția C: a calculatorului.

Testare

Pentru testare s-a folosit calculator cu sistemul de operare Windows XP și cu procesor Intel Core 2 Duo E6600.

Specificațiile tehnice ale procesorului care sunt utilizate sunt:

Procesorul suportă EIST

Gama tensiunilor suportate : Vmin = 0.85V – Vmax = 1.5V

Pasul tensiunii Vstep = 12,5mV

Tensiunea minimă Vid0 = 0,825V

Frecvența normală de funcționare : 2.4GHz

Frecvența de magistrală FSB = 266MHz

Astfel se poate crea tabela stărilor de performanță a procesorului:

Cazuri de testare:

După fiecare acțiune descrisă se verifică fișierul creat.

Instalarea driverului

Punerea calculatorului în starea StandBy

Repornirea calculatorului.

Rezultate

La instalarea driverului

Nu se transmit pachete de tip IRP_MJ_POWER, runtina DispatchPower nu este apelată.

La trezirea din starea StandBy se obține fișierul de ieșire:

Enter DispatchPower

Execute IRP_MN_QUERY_POWER SYSTEM 2

Enter DispatchPower

Execute IRP_MN_SET_POWER SYSTEM 2

System state is 2

Read from MSR IA32_PERF_STS hi 9280928

Read from MSR IA32_PERF_STS lo 600061b

Got current FREQUENCY: 1596

Enter DispatchPower

Execute IRP_MN_SET_POWER SYSTEM 1

System state is 1

Read from MSR IA32_PERF_STS hi 9280928

Read from MSR IA32_PERF_STS lo 6000928

Got current FREQUENCY: 2394

Interpretarea rezultatelor:

Prima intrare în rutina DispatchPower este o cerere de interogare a driverului dacă sistemul poate trece într-o stare de consum mai redusă.

A doua intrare în rutină se înregistrează datorită faptului ca sistemul a acceptat schimbarea de stare și trece în starea cu consum cel mai redus înainte de a intra în starea StandBy.

Valoarea citită din registrul IA32_PERF_STS a primilor 16 biți(cei care ne interesează) este 061b. Valoare multiplicatorului de frecvență dat de biții 11-8 este 6, și se observă că valoarea frecvenței corespunzătoare corespunde cu starea din tabela de P-states.

Valoarea tensiunii citite din registru corespunde și ea cu acceași stare din tabela de P-states descrisă de frecvența citită.

A treia intrare în rutină este la trezirea sistemului din starea de StandBy. Sistemul pornește întotdeauna în starea de consum maxim.

Valorile citite de multiplicatori ai tensiunii și frecvenței corespund aceleași stări din tabela de P-states.

După repornirea calculatorului

Driverul se încarcă după ce calculatorul a pornit, astfel că nu se mai face nici o schimbare a stării de consum.

Concluzii – mai trebuie scris la concluzii + 20 de carti in bibliografie + note de subsol ; minim 50 de pagini

Tehnologia Enhanced Intel SpeedStep a revoluționat power managementul prin centralizarea implementărilor hardware în procesor. De asemenea, oferind aplicațiilor software un control mai mare asupra mecanismului de tranziție al stărilor de performanță, aceste tranziții pot fi controlate dinamic pentru a satisface cât mai bine nevoile utilizatorilor.

Bibliografie

Advanced Configuration and Power Interface Specification,

Revision 4.0a, April 5, 2010

http://www.acpi.info/spec.htm

Enhanced Intel SpeedStep Technology for the Intel Pentrium M

http://download.intel.com/design/network/papers/30117401.pdf

Programming The Windows Driver Model, Walter Oney

Enhanced Intel SpeedStep – Project OS X Forums

http://www.projectosx.com/forum/index.php?showtopic=610

MSDN Library

http://msdn.microsoft.com/en-us/library

Model specific registers – OSDev Wiki

http://wiki.osdev.org/Model_Specific_Registers

Dynamic Voltage Scaling

http://en.wikipedia.org/wiki/Dynamic_voltage_scaling

Dynamic Frequency Scaling

http://en.wikipedia.org/wiki/Dynamic_frequency_scaling

Driver Development Part 1: Introduction to Drivers

http://www.codeproject.com/KB/system/driverdev.aspx

Curs Proiectarea Driverelor

Intel Core 2 Duo Processor E6600

http://ark.intel.com/Product.aspx?id=27250

Everything you need to know about the CPU C-states power saving modes

http://www.hardwaresecrets.com/article/611

Notes on Intel Pentium Processor (cpuid, rdmsr, wrmsr)

http://www.intel-assembler.it/portale/5/intel-pentium-instruction/cmpxchg8b-cpuid-mov-rdmsr-rdtsc-rsm-wrmsr.asp

Undervolt Laptop Guide – Intel C2D T7500

http://www.overclock.net/laptops-netbooks/308654-undervolt-laptop-guide-intel-c2d-t7500.html

Tech ARP – PC Power Management Guide Rev 2.0

http://www.techarp.com/showarticle.aspx?artno=420&pgno=0

Bibliografie

Advanced Configuration and Power Interface Specification,

Revision 4.0a, April 5, 2010

http://www.acpi.info/spec.htm

Enhanced Intel SpeedStep Technology for the Intel Pentrium M

http://download.intel.com/design/network/papers/30117401.pdf

Programming The Windows Driver Model, Walter Oney

Enhanced Intel SpeedStep – Project OS X Forums

http://www.projectosx.com/forum/index.php?showtopic=610

MSDN Library

http://msdn.microsoft.com/en-us/library

Model specific registers – OSDev Wiki

http://wiki.osdev.org/Model_Specific_Registers

Dynamic Voltage Scaling

http://en.wikipedia.org/wiki/Dynamic_voltage_scaling

Dynamic Frequency Scaling

http://en.wikipedia.org/wiki/Dynamic_frequency_scaling

Driver Development Part 1: Introduction to Drivers

http://www.codeproject.com/KB/system/driverdev.aspx

Curs Proiectarea Driverelor

Intel Core 2 Duo Processor E6600

http://ark.intel.com/Product.aspx?id=27250

Everything you need to know about the CPU C-states power saving modes

http://www.hardwaresecrets.com/article/611

Notes on Intel Pentium Processor (cpuid, rdmsr, wrmsr)

http://www.intel-assembler.it/portale/5/intel-pentium-instruction/cmpxchg8b-cpuid-mov-rdmsr-rdtsc-rsm-wrmsr.asp

Undervolt Laptop Guide – Intel C2D T7500

http://www.overclock.net/laptops-netbooks/308654-undervolt-laptop-guide-intel-c2d-t7500.html

Tech ARP – PC Power Management Guide Rev 2.0

http://www.techarp.com/showarticle.aspx?artno=420&pgno=0