OS Layer 2: Remember OS is a layer bet ween t he under lying - - PDF document

SLIDE 1

1

• 1

2: Archit ect ural Underpinnings and Applicat ion Requirement s

1/ 11/ 2004 8:59 PM

• 2

OS Layer

Remember OS is a layer bet ween t he under lying

har dwar e and applicat ion demands

OS f unct ionalit y det er mined by bot h

Feat ur es of t he har dwar e Demands of applicat ions

Applicat ions Operat ing Syst ems Hardware

• 3

Raw Mat erials

What does t he OS have t o work t o provide

an ef f icient , f air, convenient , secure comput ing plat f orm?

Raw har dwar e

CPU ar chit ect ur e (inst r uct ion set s, r egist er s,

busses, caches, DMA cont r oller s, et c.)

Per ipher als (CD-ROMs, disk dr ives, net wor k

int er f aces, et c.)

• 4

Comput er Syst em Archit ect ure

ALU Cont r ol

• 5

CP U

Regist er s

• Local st or age or scr at ch space

Ar t himet ic logic unit (ALU)

• Addit ion, mult iplicat ion, et c (int eger and/ or f loat ing point )
• Logical oper at ions like t est ing f or equalit y or 0
• Operat ions perf ormed by loading values int o regist ers f rom

memory, operat ing on t he values in t he regist ers, t hen saving regist er values back t o memory

Cont r ol unit

• Cause a sequence of inst ruct ions, st ored in memory t o be

ret rieved and execut ed

• Fet ch inst r uct ion f r om memor y, decode inst r uct ion, signal

f unct ional unit s t o car r y out t asks

• PC = program count er cont ains memory address of

inst ruct ion being processed

• I R – inst ruct ion regist er – copy of t he cur r ent inst r uct ion
• 6

Bus and Memory

Bus

Address lines, dat a lines, some lines f or arbit rat ion I nt ernal communicat ion pat hway bet ween CP

U, memory and device cont rollers

Somet imes one syst em bus; somet imes separat e memory

bus and I / O bus Memor y

Bot h dat a and inst ruct ions must be loaded f rom memory

int o t he CP U in order t o be execut ed

To access memory, address placed in memory address

regist er and command regist er writ t en

Range of memory addresses? Size of dat a regist er?

Det ermined by memory t echnology

SLIDE 2

2

• 7

Devices

Device cont r oller s

Small processing unit s t hat connect a device t o t he

syst em bus

Regist ers t hat can be read/ writ t en by CPU

• command regist er (what t o do), st at us regist er (is t he

device busy? Has t he device complet ed a r equest ?) , dat a regist er t o st ore dat a bring writ t en t o t he device or read f rom t he device

Device dr iver s

Sof t ware t o hide t he complexit ies of t he device

cont roller int erf ace behind a higher level logical AP I

Example: read lba 10 inst ead vs. writ e command value

0x30 t o command regist er, address 10 t o address regist er,…

• 8

Bet t er Raw Mat erial?

The “bet t er” t he underlying hardware, t he

bet t er comput ing experience t he OS can expose

Cert ainly t he f ast er t he CP

U, t he more memory, et c. t he bet t er experience t he OS can expose t o applicat ions

Also t here are some f eat ures t hat t he

hardware can provide t o make t he OS’s j ob much easier

Let s see if we can guess some…

• 9

Enf orcing P rot ect ion

I f we want t he operat ing syst em t o be able

t o enf or ce pr ot ect ion and policies on all user processes, what can give t he OS t he power t o do t hat ?

Pr ot ect ed I nst r uct ions Deny applicat ions dir ect access t o t he har dwar e Pr ot ect ed Mode of Execut ion (user vs ker nel) Memor y pr ot ect ion har dwar e

• 10

P rot ect ed I nst ruct ions

I f you would look over t he assembly language f or a

comput er , you may not ice t hat some inst r uct ions look pr et t y danger ous

Should any applicat ion be allowed t o direct ly execut e t he

halt inst ruct ion? Denial of service at t ack?

Should any applicat ion be allowed t o direct ly access I / O

devices? Read any ones f iles f rom disk? Har dwar e can help OS by designat ing some

inst r uct ions as pr ot ect ed inst r uct ions t hat only t he OS can issue

How can t he har dwar e t ell whet her it is OS

(ker nel) code or user code?

• 11

P rot ect ed Mode

I n addit ion t o designat ing cer t ain inst r uct ions as

pr ot ect ed inst r uct ions, t he har dwar e would need t o be able t o dist inguish t he OS f r om user apps

Most ar chit ect ur es have a “mode” value in a

pr ot ect ed r egist er

When user applicat ions execut e, t he mode value is set t o

• ne t hing

When t he OS kernel execut es, t he mode value set t o

somet hing else

I f code running in user mode, an at t empt t o execut e

prot ect ed inst ruct ions will generat e an except ion

Swit ching t he mode value must of course be prot ect ed

Some ar chit ect ur es suppor t mor e pr ot ect ion

modes t han j ust user / ker nel

• 12

Swit ching Modes

So how do we swit ch bet ween an OS

r unning in ker nel mode and an applicat ion r unning in user mode?

OS could set t he mode bit t o a dif f erent mode

bef or e allowing t he applicat ion t o r un on t he CPU

I f an applicat ion needs t o access a pr ot ect ed

r esour ce t o accomplish it s t ask (like r ead a f ile

• r send a message on t he net wor k), how can it

do t hat at user mode? Once an applicat ion is r unning how can we

f orce it t o relinquish cont rol?

SLIDE 3

3

• 13

Syst em Calls

I f an applicat ion legit imat ely needs t o access a

pr ot ect ed f eat ur e (Ex. r ead a f ile f r om disk, it calls a special OS pr ocedur e called a “syst em call”

Syst em call inst ruct ion execut ed wit h a paramet er t hat

designat es specif ic call desired and any ot her paramet ers needed

The st at e of t he user program is saved so t hat it can be

rest ored (cont ext swit ch t o t he OS)

Cont rol passed t o an OS procedure t o accomplish t he

t ask and mode bit changed!

OS procedure runs at t he request of t he user program

but can verif y t he user program’s “right s” and ref use t o perf orm t he act ion if necessary

On complet ion of t he syst em call, t he st at e of user

program including t he old mode bit is rest ored

• 14

Syst em Call I llust rat ed

User mode Kernel mode File.open(“/ home/ README”) Save user r egist er s and mode, lookup SYS_OPEN in a t able of syst em call pr ocedur es, Change mode bit , j ump t o t he ker nelOpen procedure Syst emCall (SYS_OPEN, “/ home/ README”) kernelOpen(“/ home/ README”, t his applicat ions access right s) Resume applicat ion wit h f ile

• pened or er r or

Rest ore user mode and applicat ion’s regist ers et c.

• 15

Memory P rot ect ion

All code t hat execut es on t he CPU must be loaded

int o memor y (it s code, it s dat a, et c.)

I t is execut ed by set t ing t he program count er regist er

t o point t o t he memory locat ion of t he next inst ruct ion t o execut e (add, j ump, load, st ore, et c.) OS has it s code in memor y and so does each

r unnable user pr ocess

Would we want a pr ocess t o st or e r andom dat a

int o t he OS’s code or dat a segment s? What about int o anot her pr ocesses code or dat a segment s?

What pr event s t his?

• 16

Simple Memory P rot ect ion Hardware

Give each pr ocess a cont iguous set of memor y

addr esses t o use and dedicat e t wo r egist er s t o specif ying t he t op and t he bot t om of t his r egion

Of course, changing t he base and limit regist er must be

prot ect ed! Memor y pr ot ect ion har dwar e gener ally mor e

power f ul t hat base and limit r egist er s (page t ables, TLB, et c.)

OS Process 1 Process 2 Base regist er Limit regist er When pr ocess 1 execut ing, base and limit set t o point t o process 1’s memory region if process 1 t ries t o load

• r st ore t o addresses out side t his

r egion t hen har dwar e will t r ansf er cont r ol t o t he OS

• 17

Transf erring Cont rol t o t he OS

A syst em call causes cont rol t o be

t ransf erred t o t he OS at t he applicat ion’s request

Ot her t hings can cause cont rol t o be

t ransf erred t o t he OS but not at t he applicat ion’s request

Could be t hat t he applicat ion did somet hing

wr ong like t r ied t o addr ess memor y it shouldn’t

• r t ries t o divide by 0, et c.

Could be t hat a har dwar e device is r equest ing

ser vice

• 18

Concret e Example: I nt el CP U

Dur ing OS init ializat ion:

I nt errupt Descript or Table (I DT) loaded wit h handlers

f or each kind of int errupt

Syst em call is int errupt vect or 128 (0x80) Kernel code segment is set t o have privilege level 0 (user

code runs at 3) Ent r y in I DT cor r esponding t o vect or 128 is set

wit h:

P

• int er t o t he kernel code segment and of f set of t he

syst em call handler in t his segment

P

ermission f or code running at level 3 t o invoke it To make syst em call, user level app:

Set s eax regist er t o t he syst em call number Execut es “int 0x80” inst ruct ion

SLIDE 4

4

• 19

A Day in t he Lif e of t he OS

When a machine r eboot s, t he oper at ing syst em will

execut e f or some t ime t o init ialize t he st at e of t he machine and t o st ar t up cer t ain syst em pr ocesses

Once init ializat ion is complet e, t he OS only

execut es when some “event ” (e.g. syst em call, device int er r upt ) occur s t hat r equir e it s at t ent ion

When an event occur s

The current st at e of t he machine is saved The mode changes t o prot ect ed mode An event handler procedure is execut ed (handlers f or all

possible event s must be specif ied)

• 20

I nt errupt s and Except ions

Two main t ypes of event s Except ions ar e caused by sof t war e

Normal sof t ware request s f or OS service are called

“t raps”

Sof t ware errors t hat t ransf er cont rol t o t he OS are

called “f ault s” I nt er r upt s ar e caused by har dwar e (e.g. device

not if ies CPU t hat it has complet ed an I / O r equest )

War ning: Under st and t he var ious t ypes but don’t

worry t oo much about t he names

Somet imes syst em calls called sof t ware int errupt s Somet imes say “t rap t o t he OS” t o handle a hardware

int errupt

• 21

Overlapping I / O and Comput at ion

I f we want t he OS t o be able t o ef f icient ly

keep t he CPU busy, t hen I / O devices need t o be able t o operat e independent ly

Even if CPU can do ot her wor k while I / O is

pending, syst em is st ill inef f icient if CPU const ant ly needs t o check f or I / O complet ion (polling)

I nt er r upt s DMA Buf f er ing

• 22

I nt errupt Driven I / O

CPU uses special inst r uct ions or wr it es t o special

memor y addr esses (memor y mapped I / O) t o init iat e t he I / O r equest

Device will per f or m t he r equest while t he CPU

does ot her wor k

When t he r equest is complet e, t he device will send

an int er r upt signal t o t he CPU via a shar ed bus

I nt er r upt causes cont r ol t o t r ansf er t o t he OS

(even if an applicat ion is in t he middle of execut ion)

I nt er r upt handler saves t he cont ext of t he

cur r ent pr ocess and t hen uses t he int er r upt t ype t o index int o a vect or t able of r out ines

Cont r ol swit ches t o t he pr ocedur e r egist er ed in

t he t able t o handle t he specif ic int er r upt

• 23

I nt errupt ing int errupt s?

What happens if get anot her int errupt

while processing one? I nf ormat ion about f irst int errupt could be lost

Disable int er r upt s while pr ocessing an

int errupt

When f inished processing an int errupt ,

check ot her devices wit h pending request s f or a “done” st at us

• 24

I nt el Archit ect ure’s P I C

Pr ogr ammable I nt er r upt Cont r oller (PI C) is a chip

t hat of f loads some int er r upt pr ocessing f r om t he main CPU

Ser ves a r ef er ee t o pr ior it ize int er r upt signals

and allows devices t o pr event conf lict s

Device int errupt s go t o t he P

I C; P I C det ermines which device raised t he int errupt ; Sends int errupt t o t he CPU wit h a value indicat ing t he int errupt service rout ine t o invoke

I f mult iple int errupt s, P

I C will buf f er t hem and send t hem one at a t ime t o t he CP U Tr eat ed by t he main CPU as a per ipher al

SLIDE 5

5

• 25

Request P rocessing Wit h I nt errupt s

To issue a r equest , OS execut es t he “t op half ”

init iat es r equest pr ocessing

Check if device is available I f so writ e command, address and dat a regist ers St ores inf o about t he request issued CP

U ret urns t o ot her processing; device cont roller get s busy working on request When r equest is done, “bot t om half ” complet es

request

device cont roller int errupt s t he CP

U, f inds int errupt handler and ret rieves inf o st ored about t he request

CP

U copies dat a f rom t he device cont roller regist ers t o main memory if needed

Set s device st at us t o available

• 26

DMA

St ill if we want t o t r ansf er lar ge chunks of dat a,

CPU will st ill need t o be ver y involved

For each small chunk of dat a, CPU must writ e a command

t o t he command and address regist ers and t ransf er dat a t o/ f rom t he dat a regist er

Very regular pat t ern

DMA or Dir ect Memor y Access aut omat es t his

pr ocess and pr ovides even gr eat er over lap of comput at ion and I / O

Tell device cont roller wit h DMA: St art ing memory

address and lengt h and it will get each piece direct ly f rom memory as it needs it

Scat t er/ gat her list : don’t limit it t o single st art / lengt h

• 27

Buf f ering

St ill mor e can be one t o over lap comput at ion and

I / O

What if I / O is slow enough and r equest ed

f r equent ly enough, all pr ocesses may be wait ing f or I / O

I / O bound vs comput e bound j obs

For wr it es, copy dat a t o a buf f er and t hen allow

pr ocess t o cont inue while dat a is wr it t en f r om buf f er t o device

I f syst em crashes?

For r eads, r ead dat a ahead in ant icipat ion of

demand

• 28

Memory Mapped I / O

For each device, set aside a r ange of memor y t hat

will be mapped t o t he r egist er s of t he device

The CPU t hinks it is r eading/ wr it ing memor y

locat ions (same inst r uct ions, same addr essing scheme)

Wit hout memor y mapped I / O, CPU needs a way t o

name each r egist er on each device cont r oller

Special inst ruct ions? Device/ regist er addresses? Required knowledge of number and t ype of devices at

design t ime

• 29

Regaining t he CP U

I f a user applicat ion is r unning on t he CPU, what

can t he OS do t o make it yield t he CPU af t er it s t ur n?

Timer (clock) operat ion Timer generat es int errupt s on a regular int erval t o

t ransf er cont rol back t o t he OS What will t he OS due when it r egains cont r ol?

Give anot her applicat ion a chance t o r un

Which one? Scheduling How? Cont ext Swit ch More on t his lat er…

• 30

Synchronizat ion

When we wr it e a pr ogr am, we t hink about adj acent

inst r uct ions happening in or der wit hout int er r upt ion

We’ve seen lot s of t hings t hat can int er r upt t he

execut ion of a pr ocess (t imer s, I / O r equest complet ion, et c.)

Most t imes t his is ok; t he st at e of our process is

rest ored and t he illusion is maint ained

But somet imes it is really import ant t hat t wo t hings

happen t oget her wit h no int errupt ion

Specif ically if t wo processes are sharing resources

• Example: t wo pr ocesses updat ing a shar ed dat abase of

account balances; one r eads balance and adds $100, one reads balance and removes $100

SLIDE 6

6

• 31

Hardware support f or Synchronizat ion

Need a way t o guar ant ee t hat a sequence of

inst r uct ions occur at once – at least wit h respect t o ot her ent it ies t hat ar e accessing t he same dat a

Solut ion 1: Disable I nt er r upt s

Unt il r e- enabled, inst ruct ion sequence will run t o

complet ion

Would you like t o allow applicat ions t o do t his?

Solut ion 2: Pr ovide Locks

Acquire lock, perf orm sequence, release lock Sequence may be int errupt ed but int errupt ion not visible

t o ot hers because t hey wait t o acquire t he lock

• 32

Building Locks

Acquir ing a shar ed lock is t he same pr oblem as

updat ing a shar ed bank balance

Har dwar e can pr ovide a gr ouping of inst r uct ions

t hat it will guar ant ee t o happen at omically

Test and set , read/ modif y/ writ e From t hese build locks, f rom locks build any at omic unit

Read balance ($300) Read balance ($300) Decrement $100 ($200) I ncrement $100 ($400) Writ e balance ($200) Writ e balance ($400) Wit hdrawal lost ! I s lock f r ee? (yes) I s lock f r ee? (yes) Wr it e “I ’ve got lock” Wr it e “I ’ve got lock” Pr oceed t o access Pr oceed t o access Concur r ent access violat ing lock!

• 33

OS Layer

OS f unct ionalit y det ermined by bot h

Feat ur es of t he har dwar e Demands of applicat ions Applicat ions Operat ing Syst ems Hardware

• 34

P rogrammers/ users demand perf ormance

User s want t o r ealize t he f ull “adver t ised”

capabilit y of a har dwar e r esour ce

I f t hey have a disk capable of 20 MB/ sec t ransf er rat e,

t hen t hey would like t o be able t o read f iles at t hat rat e

I f t hey have a net work int erf ace card capable of 100

Mbit / sec t ransmission rat e, t hen t hey would like t o be able t o send dat a at t hat r at e Oper at ing Syst em usually pr ovide t he desir ed

f unct ionalit y at a cost of some over head (t ax like t he gover nment )

Avoid seek and rot at ional delay when reading/ writ ing t o

t he disk

Avoid cont rol messages sent over t he net work Use a minimum of memory/ disk space

Pr ogr ammer s/ user s want t hat t ax t o be at a

minimum

• 35

P erf ormance Opt imizat ion

Oper at ing syst ems t r y t o opt imize t heir

algor it hms t o minimize t he “t ax” on applicat ions

What algor it hms minimize t he t ax? That is a har d

quest ion – depends on what your wor kload is

Example: What dat a do you keep in memor y?

LRU is generally good but is exact ly t he wrong t hing f or

large sequent ial accesses Opt imize f or t he “common” case? Adapt ? Let

applicat ions give hint s?

• 36

OS Goals

So oper at ing syst ems should:

Abst ract t he raw hardware P

rot ect apps f rom each ot her

Not allow applicat ions t o monopolize more t hat t heir f air

share of syst em resources

P

rovide desired f unct ionalit y

Expose t he raw capabilit y of t he hardware, minimizing

t he “t ax”

Opt imize f or t he expect ed (any?) workload Be simple enough t hat t he code execut es quickly and can

be debugged easily Does t his sound like a big j ob t o anyone?

SLIDE 7

7

• 37

Out t akes

• 38

P rogrammers/ users demand f unct ionalit y

Oper at ing syst ems pr ovide commonly needed

f unct ionalit y

P

rogrammers want st able st orage, want t o be able t o share cont ent s wit h ot her apps => f ile syst em wit h naming scheme shared by all processes

P

rogrammers don’t want t o deal wit h paging t heir own code and dat a in and out of limit ed physical memory (and want prot ect ion/ isolat ion f rom ot her processes) => virt ual memory

P

rogrammers want running processes t o be able t o communicat e (not complet e prot ect ion and isolat ion) => shared memory regions, pipes, socket s, event s

Users don’t want a single t ask t o be able t o monopolize

t he CP U => preempt ive scheduling

Users want t o be able t o designat e high and low priorit y

processes => priorit y scheduling

…

… .

• 39

Applicat ion demands exceed OS f unct ionalit y?

Not all applicat ions are happy wit h t he

• perat ing syst em’s services

Many t hings an operat ing syst em does,

applicat ion programmers could do on t heir

• wn if t hey were suf f icient ly mot ivat ed

Examples:

Dat abases t r adit ionally ask f or a r aw disk

par t it ion and manage it t hemselves (who needs t he FS?)

User-level t hr ead libr ar ies can be mor e

ef f icient t han ker nel level t hr eads

• 40

Applicat ion Moves I nt o t he OS

I f a comput er syst em is going t o be used,

f or one applicat ion, can avoid over head of crossing user/ kernel prot ect ion boundary by put t ing t he applicat ion in t he kernel

• 41

Driving f orces f or OS development ?

Many t imes plat f or m implies oper at ing syst em;

syst em har dwar e usually mar ket ed mor e t han OS

Choice of OS f or t he PC plat f or m is not t he nor m Even on PC plat f or m, what dr ives OS development

Applicat ion mix, st abilit y, polit ics bigger f act ors t han OS

f eat ures?

OS f eat ures driven by st abilit y and ease of

port ing/ writ ing apps All t his implies OS you use ever y day doesn’t

f ollow t he bleeding edge like har dwar e