Operativsystemer. Tobias Brixen Q2-2012

Transkript

1 Operativsystemer Tobias Brixen Q

2 Contents 1 Operativsystermer - oversigt OS som abstrakt og virtualiseret maskine, og som resurseadministrator Systemkald User mode og privileged mode, interrupts og traps Processer og tråde Motivation Proces- og trådbegreberne Implementation af processer og tråde, process control blocks Procestilstande Proceskoordinering Motivation Kritiske regioner og gensidig udelukkelse Uden abstraktioner TSL og Semafor Betingelsesvariabler + monitors Schedulering Motivation Schedulering: batch-, interaktive- og realtids-systemer Schedulering af tråde Lageradministration - Basale elementer Motivation Lageradministration uden abstraktion Opdeling af lager Lageradministration - Virtuelt lager Motivation Paging og segmentering Udskiftning af sider, page replacement algoritmer Filsystemer Motivation Filbegrebet, komponenter i et filsystem Filtyper, filstruktur, filattributter Kataloger (directories), hardlinks/symlinks Implementation af filer, sammenhængende blokke, kædede lister, FAT, inodes Input/Output - Basale elementer Motivation Håndtering af I/O, device-uafhængigt og device-afhængigt software, device drivers Kommunikation med ydre enheder, memory-mapped I/0 eller specielle I/O instruktioner, polling/interrupts/dma Brug af buffere og caches Page 2

3 9 Input/Output - Devices Motivation Diske og deres data (Diske, organisering af data på en disk, disk schedulering) RAID Stable storage Tastaturer/terminaler, canonical/non-canonical mode, escape-sekvenser Deadlocks Motivation Begrebet deadlock, definition, Coffman s betingelser Deadlock modellering: operationer og resurse-grafer Deadlock detection (en eller flere resurser pr type) og recovery Deadlock avoidance, Banker s Algorithm Deadlock prevention Page 3

4 1 Operativsystermer - oversigt Disposition OS som virtualiseret og abstrakt maskine, og som resurseadministrator Systemkald User mode og privileged mode, interrupts og traps 1.1 OS som abstrakt og virtualiseret maskine, og som resurseadministrator Virtualliseringen kommer ind i billedet når man fx kikker på processer. Processerne, tror de har adgang til en hel CPU hver og et stort addresseområde, men det der egenligt sker er at de, uden at vide det, bliver scheduleret væk fra CPU en, for at lade, andre komme til. OS et abstraherer en del ting væk for os som bruger at OS et, og har til formå at vi kan interagere nemmere med med vores computer. OS et kan gøre det ved imlementeringen af kernel laget som har at gøre med disk-interaktion, og styring af processer, og så det lidt højere lag af system libs. For at kunne bruge services som OS er har, skal man lave det der hedder en system call. Måden det sker på er at man trapper ind i systemet, og man går fra usermode til kernel mode. Man går fra progarm til lib-procedure, sys-call nummer på stakken, trapper, en dispatcher i kernel, ser på sys-call nummeret og vi går hen til en handler, som hører til det nummer, udfører det skal gør (her fopen), og returnerer. Interrupts er mer epå hardware niveau, fx en disk skal sige til CPU en at den er færdig med at læse det den havde fået besked på. Page 4

5 1) Driver fortæller disken at læse. 2) Disken interrupter til interrupt controlleren. 3) Hvis ikke interrupt controlleren er i gang med en højere prirotets interrupt, asserter den CPU en at der er et interrupt 4) her sendes device ID videre til CPU en som slår op i en interupt vektor for at finde interrupthandeleren for det besteme device. 1.2 Systemkald for at abstrahere væk.. os som api til resourser. 1.3 User mode og privileged mode, interrupts og traps 2 Processer og tråde Disposition Proces- og trådbegreberne (re)start af processer Process control blocks Tråde Procestilstande 2.1 Motivation 2.2 Proces- og trådbegreberne Processbegrebet En process er et kørende program, hvor programmet er koden af processen. Hver process tror den har sin egen CPU, men det der egenligt Page 5

6 sker er at de deles om den ene og samme cpu. Dette kalder vi multiprogrammering. Vi kan også set det som bestående af to dele: recourse grouping og execution Trådbegrebet En tråd er så den form for execution indenfor en process, hvor multithreading er at der er flere tråde inden for same process, og giver mulighed for at kunne arbejde på et word dokument på samme tid som den auto-saver. Klassisk model: Processen holder åbne filer, child processes, signal handlers mm. hvor en thread er execution-delen af processen; den har PC, registers, stack og en state. Dvs. hvis processen åbner en fil, kan alle tråde læse og skrive til den. Som ved en process kan en tråd være blocked, ready eller running. 2.3 Implementation af processer og tråde, process control blocks Lidt mere implementationsnært for UNIX starter har vi PCB eller: Process Control Blocks/Process table Et array af structs, én for hver process. Den indeholder staten for hver process; program counter, stack pointer, memory allocation, åbne filer mm.. Dvs. den indeholde al information vi skal bruge til at suspendere, og genstarte en process. Se fig 2-4 for mere. Når vi på den anden siden skal starte en process forker vi en præcis (næsten; PID) kopi af processen; altså med samme kode, andress space, envioment strings og åbne filer. Efter fork køres exec for at ændre memory image et. Hvorfor denne to-step process? For at der er tid til at redirecte stdin, stdout og stderr. Page 6

7 Tråde Userspace Kernen tror stadig den kun bare har med processer at gøre, og kender ikke noget til det library som er implementeret på process nivueau Fig 2-16 (a). Hver process har sin egen thread table, og indeholder hvad der er nødvendigt for en thread kan genstartes. Fordelen ved userspace implementationen er at der går ikke tid med contextswtiches, cpu-trapping, mm. Problemet med userspace er ved blocking systemcalls, fx læs fra keyboard; da dette blokerer hele alle trådene 1. Ved page-fault blokeres alle threads også. Kernelspace Her styrer kernen det hele som set på Fig 2-16 (b). Kernen vælger hvilke tråde der skal køres, og kernen har thread table, state o.a. information. Da der er stor overhead på at oprette tråde er destruerer men ikke tråde når de slettes, de bliver bare markeret som not runnable ; dette kaldes thread recycling. Det er dog smart hvis en tråd laver en blokerer på input, da kernen bare kan se efter en anden tråd at køres. Af andre ulemper er det at systemkald koster dyrt; så hvis der ofte skal oprettes, nedlægges og der stor overhead på denne implementation. Hybrid Den ultimative løsning er en sammensmeltning mellem de to implementationer + at programmøren har så kontrol. Kernen schedulerer de tråde som er oprettet til kernen, og ud fra disse kan der multiplexes user-level tråde, som vi bliver oprettet, nedlagt og scheduleret i user-level. 1 man kan dog lave et tjek før man laver blocking systemkald, for at se om den bliver blocked, men for at det skal fungere, skal der en wrapper af en art til Page 7

8 2.4 Procestilstande 1 Running (I gang med at bruge CPU en) 2 Ready (runnable, men stoppet for at lade en anden cpu have cpu en) 3 Blocked (indtil et eksternt event er sket) Transition 1: Når der læses fra pipe eller special file, og ingen input er tilgængelig Transition 2 og 3: Bliver lavet af scheduleren, uden processen kender noget til det. Transition 4: Når input så kommer, bliver den ready. 3 Proceskoordinering Disposition Kritiske regioner og gensidig udelukkelse Uden abstraktioner TSL, Semaforer betingelsesvariabler, monitors Page 8

9 3.1 Motivation Når vi tilføjer flere tråde, giver det os problemer med delte resurser. Fx mht. raceconditions; at forskellig interleaving fører til forskellig output. 3.2 Kritiske regioner og gensidig udelukkelse For at løse det problem indfører vi et begreb kaldet kritisk region, som er den del af koden som tilgår den delte resurse. Altså hvis vi opnå at der er en, og kun én, process/tråd inde i dens kritiske region ad gangen, kan vi undgå problemer. Altså en form for gensidig udelukkelse (mutual exclution) af tråde fra deres kritiske region. Med det kan der også komme problemer, da vi kan få gensidig udelukkelse. Det kan vi undgå ved at: Processer uden for critical section (CS) må ikke forhindre andres adgang til deres CS En process der gerne vil ind i CS, kommer ind (no starvation) Processer må ikke gensidig udelukke hinanden (no deadlocks) Processer må ikke altid gensidigt udsætte adgang til CS (no livelock) 3.3 Uden abstraktioner Der er flere forskellige måde vi kan opnå mutual exclution på. Strengalternering hvor en streng styrer hvem der har adgang. Når en process 0 er færdig med sin CS sætter den så strengen til noget andet end 0; fx 1. Problemet er her at det er naivt at tro at kritiske regioner er lige store. Schedulerinteraktion Vi fortæller scheduleren at den skal lade være med at schedulere mig væk, indtil at jeg siger til. Petersons algorithm Løser mutual exclution (uden brug af atomare operationer) for to tråde, der vil tilgå samme resurce. Den bruger turn som er en delt variabel og et array over hvem der er interesseret i at gå ind i CS. Så længe at jeg mener at det er min tur (turn) til at gå ind i CS, og den anden er interesseret i at gå ind i CS, busy-waiter (spin-lock) jeg. 3.4 TSL og Semafor TSL Og så den meste simple test-set-lock (TSL). Det er en atomar operation der sætter en lock til 1, og returnerer værdien der stod i locken før. Semafor Vi kan bruge TSL til at implementere semaforer. Semaforer er en abstraktion fra det hardwarenære. Den har to operationer: up og down. down tæller semaforen én ned; med mindre den er 0, så blokere den processen. Up derimod tæller semaforen en op, med mindre der er en process der kan unblockes. Det er hvad vi kalder en tællesemafor. Den har en specialisering kaldet binær semafor / mutex, hvor vi kun tillader at den kan have værdien 0 eller 1; vi Page 9

10 kan altså bruge den som en lås. Vi bruger TSL for at implementere mutex. Vi kalder TSL på en lock, og hvis så den giver os 0, var det ingen der havde locken, og vi kan gå videre i vores CS, hvis den var 1, yielder vi. Dette er vigtigt for ikke at tråden står og busy-waiter. Grunden til at vi bruger TSL er at undgå den perfekte interleaving hvor trådene, interleavet, udfører 1) få værdien fra lock 2) se at den er 0 3) skriv 1 til den 4) gå ind i CS 3.5 Betingelsesvariabler + monitors Betingelsesvariabler Bliver brugt i forbindelse med monitors. Den har to operationer: wait(c) og signal(c). Wait blokerer processen og sætter den i køen c. Signal tager en process i køen c og unblocker den. Monitors er en abstrahering der beskytter tilgang til dele resurser Man kan se en monitor som et objekt, der har procedures, hvor kun én procedure kan udføres ad gangen. At der kun er en procedure der kan udføres ad gangen beskytter helt naturligt feltvariablerne (data) mod samtidig tilgåelse. 4 Schedulering Disposition Schedulerbegrebet Batch-, interaktive- og realtids-systemer Schedulering af tråde 4.1 Motivation (Fordeling af cpu-tiden mlm processer; bl.a. interleaving) Når vi har med multiprogrammering at gøre, sker det at to programmet er i en ready state på samme tid. Det bliver bruger en scheduler til, er at vælge hvilken en af de to processer skal skal have cpu tid næste gang; det bliver gjort ud fra en schedulerings algoritme. 4.2 Schedulering: batch-, interaktive- og realtids-systemer Der er 3 overordnede strategier for schedulering. Fælles for dem er at de vil give hver process en fair share af cpu tid, og at systemet er i balance. Jeg vil se på Batch Interactive Real time Page 10

11 Batch går ud på at maksimeret output pr time; minimering af turnaround time (tiden far submission til completion); holde CPU en travlt optaget. Algoritmer batch bruger er: First-come First served (Shortest job first) Shortest remaining time next (for preemptive systermer) Hvad er preemptive systemer? I preemptive systemer kan scheduleren tage kontrollen fra en process selvom den ikke er færdig med at køre. (bliver implementeret med en clock interrupt). Modstykket er non-preemptive går en process får lovil at køre til slut / den blokerer / yielder. (bliver implementeret med en clock interrupt). Interaktive er vægter man at få minimeret responsetime, og få maksimeret bruger oplevelsen. Algoritmer for interaktive systemer: Round-Robin. Preemptive. Quantumbaseret. Spørgsmålet er her hvor stor quantum skal være vs hvor lang tid et context swtich tager vs resonstime. Lav quantum = overhead til swtich; høj quantum = lang tid mlm jobs = lav response time. Priority scheduling - Sig sig selv. Hvis der er flere processer i samme prioitetsgruppe bliver det decieded pr RR. (Shortest process next). Problemet her er at find ud af hvilken en der er kortest. En strategi kunne være at tage en gennemsnit af de sidste 4 kørsler (Guaranteed Scheduling. n brugere = 1 n CPU kraft.) (Lottery Scheduling - Hver process får en lottery ticket, og CPU holder så udtrækning 50 gange i sekundet. ) Fair-share scheduling Hver bruger eller gruppe får lige stor del af CPU en. Real-Time går ud på at man schedulere for at mødes nogle deadline. E.g. hard real time; hvis svejseren ikke når at svejse bilen på båndet. Soft real time hvor der uhensigtsmæssigt hvis deadlinen ikke er overholdt, men det kan tolereres. For at det kan implementeres skal man kende processernes udførselstid på forhånd, og være sikker på at de er schedulable. Det går ud på at den samlede tid for udførsel af alle processer ikke må overstige den totale tid for de perioder hvor de sker. 4.3 Schedulering af tråde Der er to måder (egenligt 3 med hybrid) man kan schedulere tråde på. Den ene er hvor kernen kender til tråde, og den anden er hvor det er processen der kender til tråde. Page 11

12 User-threads. Her er det processen der laver, holder styr på, og schedulerer trådene. Processen får quantum som normalt, og en tråd kan uden problemer æde det hele, hvis ikke den yeilder. Plus, hvis en tråd blokerer, er det for kernen som om hele processer blokerer, og inden tråde i den process kan fortsætte. Kernel-threads. Her holder kernen styr på det hele, og den kan godt schedulere andre tråde inden for samme process hvis en tråd blokerer. 5 Lageradministration - Basale elementer Disposition Uden abstraktion Opdeling af lager Frie blokke Indsæt og fjern blokke uden ab - opdeling af vores lager så der kan være flere programmer.. vi bruger logiske addresser og addressmaps (addressmap er fysisk addr = base + logisk) med base/limit kan vi sætter flere programmer i memory. når vi sætter programmer ind er der 4 algs når vi sletter er det to impls til at håndterer frie blokke. - hvis der kommer fragmentering bruger vi memory compaction 5.1 Motivation 5.2 Lageradministration uden abstraktion Vi kan kun have et program i memory ad gangen, og vi bruger direkte addressering. (OS et kan ligge lidt forskellige steder) OS er kan så lægge lidt forskellige steder a) OS i bunden af adresserummet. blev brugt i mainframes. b) OS i ROM. bliver brugt på embedded devices. c) som a) men med device drivers i ROM. Hvad er problemet? Vi kan trashe OS et. Selvom vi kun kan have et program i memory ad gangen kan vi stadig godt arbejde med flere programmer; vi swapper bare ud når vi skal bruge det nye program. Det tager bare utrolig lang tid at swappe til og fra disken hele tiden. Page 12

13 5.3 Opdeling af lager Da det nu tager så lang tid er swappe ind og ud, vil vi gerne kunne have mere end et program i memory ad gangen. Det gør vi med base/limit registre. Vi sætter simpelthen et program ind i memory, og siger den starter fra en addresse, og stopper et sted. Hvad går man så med addressering? enten laver man statisk relokering, og tager alle adresser og lægger basen til; eller også bruger man dynamis relokering hvor man oevrsætter adresserne når de bliver brugt. For at kunne indsætte er skal vi kunne holde styr på hvor, og hvor store de frie blokke er. Jeg vil tage to frem som er BitMap og FreeList: Håndtering af frie blokke BitMap Vi har en bit til hver allocation unit (går være fra få words til KB s), som siger om den er fri eller ej. Ulemper: Det tager alt for lang tid at søge igennem bitmappet, for at finde nok 0 er til at swappe et program ind. FreeList Sorteret pr adresse. Hvert element i listen er en segment. Et segment er enten et program eller et hul. Listen indeholder altså 4 dele: Om det er et hul eller program, startadressen, længden, pointer til næste element. For at gøre det hele nemmere kan den implementeres med double-linked list. Indsættelse af blokke Når vi så ved hvor der er frie blokke kan vi indsætte. Der er et par forskellige strategier når man indsætter programmerne: First-fit: Tag det først hul der passer. Start forfra hver gang. Next-fit: Som first-fit, men hvor vi leder videre fra der hvor vi kom til. Best-fit: Vælg det mindste hul der passer. (store huller brydes ikke) Worst-fit: Vælg det største hul der passer. (man undgår at lave mange små huller) Mod forventning er first-fit bedst, og best-fit værst. Page 13

14 Bloksammensmeltning Og når de skal slettes kan vi lave bloksammensmeltning når vi bruger FreeList Når vi hele tiden sætter ind, og tager ud, kommer der hurtigt fragmentering af vores hukommelse, for at undgå det, laver man memory-compaction. Det er dog en utrolig dyr process. Så derfor har man segmentering for mere finkornet opdeling, og endnu mere finkornet har vi så pages. 6 Lageradministration - Virtuelt lager Disposition Paging og segmentering Page frame, MMU, page-table, TLB Page replacement algoritmer 6.1 Motivation Motivationen for at have virtuelt lager, og virtuelle adresser er at programmer fylder mere end det kan være i vores main memory, og at vi ikke altid behøve at have hele programmet i memory på én gang. 6.2 Paging og segmentering Segmentering handler om at vi kan opdele vores programmer nogle naturlige steder, og kan sætte dem ind og ud af memory. Fx vores heap, datasegment osv. Dem putter vi så ind i vores memory, og swapper ind og ud som vi har brug for det. Hertil føreres en segmenttabel som har 1) segment nr 2) base 3) length. Her opstår der stadig fragmentering. Løsningen er så at lave et kæmpe stort virtuelt lager, som processen kan lege i. Det virtuelle lager er så delt op i faste størrelser kaldet pages; dermed er vores memory også det op, her kaldes de page frames. Når vi skal oversætte fra de virtuelle adresser til fysiske addresser bruger vi en MMU. MMU en får den virtuelle addresse ind, og slår op i en page-tabel, for at finde ud af i hvilken page frame, pagen ligger i. Hvis ikke pagen ligger i en page frame, opstår en page fault. Den trapper, går ud og udskifter en page i en pageframe (ud fra en algoritme), og genudfører den sidste instruktion. Page 14

15 For at vi ikke skal kikke hele vores vores page-tabel igennem hver gang, har vi den Translation Look-aside buffer som en slags cache, hvor de 64 mest er refererede. 6.3 Udskiftning af sider, page replacement algoritmer Som i page-tablen, bliver der holdt styr på hvilket nummer hver page har, om den er i en page frame, om den har være m(odified), r(eferenced), protection og om caching er disabled. Ud fra de informationer har vi forskellige algoritmer til at udskifte pages. Optimal: Hver page får et tal, svarende til antal instruktioner før end de er referenced. Pagen med det højeste tal, bliver fjernet. Denne er dog ikke mulig, da vi ikke kan se ud i fremtiden. Not Recently Used: Det er bedre at fjerne en dirty ikke-brugt page, end en clean meget-brugt page. Lowest numbered non-empty class. R bitten bliver resat efter hver clock cycle. Class 0: R: 0, M: 0 Class 1: R: 0, M: 1 Class 2: R: 1, M: 0 Class 3: R: 1, M: 1 FIFO: Den har en linked list af pages der er i memory. Headen ryger ud, og den nye kommer ind bagerst. Second-chance: Som FIFO, men hvis R er sat, ryger den om bagerst i køen med R sat til 0. Sådan bliver den ved, indtil den finder en gammel og ubrugt page. Den er dog meget ineffektiv da den flytter rundt med pages hele tiden. Clock: Hold pageframes i en cyklisk list. Pointeren peger på den ældste. Ved en pagefault inspicere vi: Hvis R = 0, bytter vi ud, og pointeren går én videre. Hvis R = 1, bliver den sat til 0, og pointeren går videre til næste. På den måde flytter vi ikke rundt med pages hele tiden. Least Recently Used: Væk med den der er ikke har været brugt længst. Aging. Vi holder 8 bits hvor vi sætter den første bit hvis den er refrenced ; vi bitshifter efter hver clockinterrupt. 7 Filsystemer Disposition Filbegrebet, komponenter i et filsystem Struktur, typer, attributter. Kataloger (directories), hardlinks/symlinks Implementation af filer, sammenhængende blokke, kædede lister, FAT, inodes Page 15

16 7.1 Motivation Problemet filer løser er: Information skal være non-volatil; overlever processterminering; flere processer skal have adgang til. 7.2 Filbegrebet, komponenter i et filsystem En fil er en logisk samling af information oprettet af en process. Delen af operativsystemet der arbejder med filer, kaldes filsystemet. I et filsystem har man basalt set to forskellige komponenter: filer, directories. Filer de kan have et navn og en type, genkendt ud fra deres endelse. I UNIX har de dog kun betydning for brugeren hvilken endelse filen har. Strukturen for en fil kan være: (a) er bare en utruktureret sekevns af bytes, og det er user-level programmer der skal give mening til de bytes. Den her model bruger både UNIX og Windows. Det er også den mest fleksible måde, da OS ikke står i vejen for noget. (b) er record based, og blev brugt da 80-char hulkort var kongen. Hver record var altså et image af hulkortet. (c) En trækstruktur, hvor hver fil indeholder 3 records. Hver record har en key. Træet er sorteret på keys, og man kan hurtigt finde key en pony, uden at tænke over hvor i filen den er placeret. Denne model bliver stadig brugt i størrer mainframe computere. 7.3 Filtyper, filstruktur, filattributter OS et skal stort set kun kende forskel på to filer: ekskvérbare og dem der der ikke er; men der findes også directories, almindelige filer, characker special files, block special files m.fl (FIFO). Filattributter/Metadata Filer kan også have attributter, hvor der er OS dependent hvilke attributter en fil har. Page 16

17 Hvor de attributter ligger er OS dependent. I Windows ligger de i directory entriet, mens i UNIX er det i i-noden. Det leder os hen til kataloger. 7.4 Kataloger (directories), hardlinks/symlinks Single-Level Directort systems Her er der kun root dir, og alle filer er samlet her. Det er et simpelt og potentielt hurtigt at søge igennem. Det bliver brugt på mindre systemer som embedded. Hierarchical Directory Systems For moderne computere er singlelevel ikke brugbart. Vi har derfor hierarkisk opbygning. Implementing Directories Page 17

18 Et directory system skal kunne mappe et ASCII navn til en fil eller directory. (a) Ved Windows har hver diretory entry også filattributter, modsat (b) UNIX hvor navnet bare givet en reference til en i-node. Delte filer Når vi deler filer mellem directories, laver vi en DAG (directed acyclig graph i stedet for vores almindelige træstruktur. Det kan dog give problemer. Hvis et directory entry indeholde alle adresserne for filen, og der bliver appended til filen, sker dette jo kun i det ene directory. Det kan løses enten ved at sige entry en indeholder en pointer til en datastruktur med blokkene, som fx ved i-nodes implementationen. Page 18

19 Hard linkning Man linker ved at lave en directory entry til i-noden, og på i-nodes tælles count 1 op; owner ændre sig ikke. Og hvad gør man når filen skal slettes? Man fjerne directory entry et fra C, men det er stadig C der ejer i-noden. Den anden løsning kaldes symbolsk linkning og går ud på at der i B s directory bliver lavet en fil af typen LINK, der indeholder path en til filen i C. 7.5 Implementation af filer, sammenhængende blokke, kædede lister, FAT, inodes MBR (Master Boot Record bliver altid læst først. Når systemet booter læser BIOS MBR, finder den aktive partition, og læser dens Boot block. For uniformitet indeholder alle partitioner en boot block, også selvom den partition ikke kan bruges til at boote op fra. Contiguous Allocation Page 19

20 Filerne bliver skrevet til blokke af en bestemt størrelse, e.g. 1KB. Hvis en fil fylder 3,5 blok bliver den sidste halvdel bare spildt. Den er simpel at implementere, da man kun skal huske to ting: startadressen og antal blokke for filen. Der er god readperformance da det kun kræver én seek, og resten er sekventielt. Den har dog også sine bagsider: Disken bliver fragmenteret. Det er ikke i praksis brugbart, bort set fra brugen i CD-ROM. Vi skal altid specificere hvor stor vores fil kommer til at være. Linked List Allocation Her bliver det første word af hver blok brugt til at pege på den den næste blok. Her er ingen fragmentering (ud over inden i den sidste blok), og vores directory entry, skal kun indeholde startadressen for hver fil. Her får vi dog et problem med readperformance, hvis vi skal bruge random access, da vi skal starte forfra hver gang. Vi bruger også et par bytes på at holde pointeren. Page 20

21 Linked List Allocation Using a Table in Memory Vi kan undgå de par ulemper ved at holde pointer word et i RAM ene i en FAT (File Allocation Table). Det vil så se ud som på Fig 4-12 (samme fil som fra Fig 4-11). Her kan vi bruge hele blokken til data, og selvom vi ved random access skal hele kæden igennem, går det noget hurtigere i RAM end på disk. Ulempen er her at hele table en skal holde i RAM. For en 200GB disk med 1KB blokke skal FAT en haven 200 millioner entries. Hver entry en mindst 3 bytes stor, 4 hvis hastigheden skal være god. Dvs 600 eller 800 MB bliver brugt på FAT. I-nodes Page 21

22 Her er filen repræsenteret filattributter, og disk adresser for filblokkene. Fordelen ift. de andre implementeringer er at I-nodes kun behøver at være i hukommelsen, når filen bliver brugt. Dvs. ifh. FAT hvor antallet af entries i tabellen er proportionel med antallet af blokke på disken, er i-nodes kun proportionel med antallet af filer åbne. 8 Input/Output - Basale elementer Slides: 12 fra IO (DMA), 16 (upræcise interrupts), 48 (overblik) Disposition (Device-)uafhængighed device drivers Memory-mapped I/0 eller specielle I/O instruktioner, DMA Brug af buffere og caches 8.1 Motivation Operativsystemer håndterer også devices, og skal kunne give kommandoer til enhederne, fange interrupts og tage sig af fejl. 8.2 Håndtering af I/O, device-uafhængigt og device-afhængigt software, device drivers Håndtering af I/O slide 48: Når en process gerne vil have adgang til et stykke hardware går det igennem mange lag. Slide 48 For at gøre interaktionen med hardware så nemt som mulig, har UNIX en ide om Page 22

23 at al hardware skal kunne ses som filer, det er en del af det man kalder deviceuafhængihed. Det betyder at der er et uniformt interface for device drivers. At et USB-drev og en CD-rom kan blive mounted på ligefod inde i /dev. Uniform interfacing for device drivers: Alt er filer i linux, der gælder beskyttelse og adgang via filsystemkald. Alle enheder findes i /dev. Man programmerer en device op i mod et interface i kernen. Buffering. OS et ved ikke hvor den skal putte den overskydende pakke til netkortet. Error reporting. Fejl skal blive fanget så tæt på hardwaren som mulig. Allocating and releasing dedicated devices Providing a device-independent block size Device afhængigt software? Device drivers At device drivers har et interface at programmerer op til betyder at kernen ikke skal ændres fordi at vi til lavet et nyt stykke hardware. 8.3 Kommunikation med ydre enheder, memory-mapped I/0 eller specielle I/O instruktioner, polling/interrupts/dma Når en device-driver skal kommunikere med et device sker det ved at den skriver en opkode og nogle operander i en device-controller, hvorefter et interrupt man kan læse resultatet fra en buffer deri. Der er to måder man kan skrive til de registre på i kontrolenheden: 1) specielle I/O instruktioner hvor man giver et device no (I/O port) med. 2) Memory-Mapped I/O her ligger adressespace i forlængelse af main memory, og kan på den måde få adgang til at skrive og læse fra kontrolenheden. (fordele for 2) ingen specieller maskininstruktioner, nem adgang til device registre på højniveausprog, beskyttelse af adgang via lageradministration. Ulemper:skal undgå caching af device registre; alle ydre enheder skal lytte på adressebus; ligner brug af lager, men er anderledes) For at CPU en ikke skal kommunikerer og vente på disken, kan CPU kommunikere med en DMA-controller (Direct memory addess). Page 23

24 Slide 12 Uden DMA: CPU en siger til controlleren: start med at læs. Disken læser så bit for bit indtil hele blokken er i bufferen. Checksum er tjekket. CPU en interruptes, og CPU en skal loope over alle words i blokken i bufferen. Med DMA Step 1) CPU en programmere DMA en med hvor mange blokke der skal skrives, og hvor den skal lægge det bag efter. Step 2) DMA en sender besked til controlleren, og den starter med at læse. Step 3) Når kontroleren tager et word fra sin buffer ved den, fra DMA en hvor den skal skrive til. Step 4) Når bufferen er tømt, sendes der en ack til DMA en, og i DMA en tælles count en ned, og adresse en op. Hvis count ikke er 0, fortsættes 2-4; hvis den er 0, sendes et interrupt til CPU en. CPU en ved nu hvor data ligger, og behøver ikke bøvle med at skulle sende det til memory. Man slår cache fra for at tager det data som lige er blevet lagt i RAM ene, og ikke nogle gamle data far cachen. polling? er at man busy-waiter på input, fra en enhed, og hele tiden prøver at få data derfra. 8.4 Brug af buffere og caches En anden del af device uafhængighed er buffering. Det giver mulighed for at man kan arbejde asynkront. hvorfor? udligning af buffer Man kan placerer bufferen enten 1) i userspace, eller 2) kernel, som så skriver til user. Problemet med 2) er hvis der kopieres til userspace, og device vil skrive til buffer i kernel; løsning = to bufferes i kernel. Interrupting Device interrupter interrupt-controlleren. Den sorterer efter en prioritet hvis der er pending interrupts. Alt efter hvilket device der har interrupted, bliver der sat en tal på address linen; det tal bliver brugt til at slå op i en tabel kaldet interrupt vektoren, som specificerer PC er til næste intruktion. Slide 16 - præcise/upræcise interrupts Hvis ikke der bliver lavet et præcist interrupt, bliver det noget bøvl for OS designeren, da han har en stor state på stakken han skal have restored bagefter (hvis e.g. der er flere instruktioner der var 10%, 40% osv. færdige). Kravene for et præcist interrupt er, bare at alt før PC er udført, alt efter er ikke udført, vi Page 24

25 ved om instruktionen på PC en er udført eller ej, og PC en gemt et veldefineret sted. 9 Input/Output - Devices Disposition Organisering af data på en disk, disk schedulering, (geometrien?) RAID Stable storage Tastaturer/terminaler, canonical/non-canonical mode, escape-sekvenser 9.1 Motivation Devices er hvad vi bruger til at interagere med computeren, og til at langtidsgemme vores data. Uden nogen form for perifere devices, ville vi bare stå med en smart klump skrot. 9.2 Diske og deres data (Diske, organisering af data på en disk, disk schedulering) Magnetiske diske bruger vi til at gemme data på, som skal overleve et crach. Disken er organiseret i tracks, der er delt op i sektorer, der igen er delt op i bytes. Disk schedulering Shortest Seek First - Se på alle, og tag den der er tættest på Elevator - Kør fra den ene end til den anden, og læs alle de punkter du skal, når du kommer forbi dem. 9.3 RAID RAID er en måde at kombinere flere disks på for at opnå større sikkerhed mod nedbrud, og bedre performance. Der findes en del RAID levels jeg hurtigt her vil gennemgå: 0 Data bliver delt over flere diske i stripes i en RR måde. (God for store mænger data, men dårlig da 4 diske = 4 gange så stor chance for fejl) 1 Mirror. (Kan skrive dobbelt så hurtigt, stort overhead, dobbelt så god reliability som SLED) 2 Et word er spred ud over diskene + hamming code for at kunne rette eventuelle fejl. (read+write er nice. Dog skal alle diskarme stå ens. Fantastisk reliability grundet hamming) 3 Simplere version af 2. Diske med en enkelt parity disk, som tjekker parity for det word der står. Page 25

26 4 som 3 men med strips i stedet. Kan være langsomt, da parity disken nok kører hele tiden, og man skal vente. God reliability, da man altid kan genskabe, en disk ud fra parity. 5 som 4, men med parity disken delt over. 9.4 Stable storage Stable storage går ud på at man gerne vil sikre sig at det man har skrevet til disken også er skrevet. (Det ligner en implementation af RAID 1?) Stable write går ud på at man skriver først til den ene, læser om det man skrev, er skrevet; hvis ikke (giver en ECC), prøver man n gange. Når det engang lykkedes går man videre til næste disk og gør det samme. Stable read går ud på at læse fra disk 1 n gange indtil det lykkede; hvis ikke har man altid disk 2. Recovery Man kører hele disken igennem for ECC. Der hvor der er en bad block, overskrive den dårlige. Page 26

27 9.5 Tastaturer/terminaler, canonical/non-canonical mode, escape-sekvenser I gamle dage da man havde tty er og brugte dem med abatraktionen som forløbende tekst, havde man escape-sekvenser, og tastaturer havde canonical og non-cannonical mode. Cannonical vs non handler om, om man fortoler det input man får fra tastaturet. Cooked mode fortolker man e.g. Ctrl-D som EOF, Ctrl-U kill line. Non mode giver os at det rå data fra tastaturet, og vi kan så vælge hvad vi vil gøre med det. fx tager vim ikke imod Ctrl-D. ANSI escapesekvenser er noget som terminaler tager imod, der handler om curser movement, men Esc M er fx scroll backwards hvis curser er i toppen. 10 Deadlocks Disposition Definition, Coffman s betingelser (modellering) Struds Detection Avoidance, Banker s Algorithm Prevention 10.1 Motivation Computere er masser af resurser, der kun kan blive brugt af én process ad gangen e.g. hardware som printere, scannere og mere softwareorienteret er der filer Begrebet deadlock, definition, Coffman s betingelser Hvis en computer med to cd-dreve har to processer, der hver har har adgangen til hver sin, og venter på at den anden process releaser adgangen, er de to processer i en deadlock. Mere formelt er definitionen på en deadlock A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause. For at deadlocks kan opstå skal vi have med nonpreemptable resources at gøre. Det betyder at en resurse ikke kan blive tage fra processen uden at der går noget galt; e.g. en cd der bliver brændt. Hvis resurserne var preemptable kunne den ene process bare hugge resursen fra den anden uden problemer. Det leder os hen til Coffman s betingelser. Disse betingelser skal alle være til stede, hvis der skal kunne opstå (resurse) deadlock i et system. 1) Mutual exclution condition. en resurse kan ikke anvendes af mere en én process (tråd) ad gangen. Page 27

28 2) Hold and wait condition. En process, der allerede har en resurse, kan bede om en mere 3) No preemption. Man kan ikke forcefully tage en resurse fra en process / frigivelse skal ske på processens eget initiativ. 4) Circular wait. To eller flere processer kan danne en cykel, hvor hver process venter på en resurse, den anden har 10.3 Deadlock modellering: operationer og resurse-grafer Elementer i modelleringen: Cirkel: Process. Firkant: Resurse. (a) A har resursen R (huskeregel: den modtager indput). (b) B spørger om adgang til S, og er blocked (huskeregel: den poker til resursen, og spørger om adgang). TODO: operationer!? Hvad gør vi så med deadlocks? Det er der overordnet 4 måde at deale med dem Strudsealgoritmen. Ignorer dem Detection and recovery. Lad dem ske, opfang dem, og handl. Dynamic avoidance; allokér resuserne smart Forebyggelse; ved at fjerne en af de fire Coffman conditions Jeg vil her gennemgå alle fire Strudsealgoritmen. Deadlocks er ikke den eneste grund til at systemer går ned. Hvis man ved at denne deadlock kun fremkommer hvert 5. år, og systemet ellers bryder ned ca hver uge pga. e.g. hardwarefejl, compilerfejl, OS bugs o.l. er det rimeligt ikke at bruge tid og performance på at fange en sådan deadlock. Page 28

29 10.4 Deadlock detection (en eller flere resurser pr type) og recovery Ved deadlock detection, finder vi bare ud af om der er en deadlock, hvis der er laver vi recovery: Recovery Hvordan kommer vi os fra en deadlock? Her er et par strategier: Gennem preemption. Hvis man er heldig kan man suspenderer et printerjob, tager den halvfærdige papirstak til side, sætter det andet job i gang og lader det kører færdigt, hvorefter man sætter stakken af papir tilbage. Gennem rollback. Hvis man ved at et system ofte deadlocker, kan man kode så man kan komme tilbage til et checkpoint. Gennem mord. Bliv ved med at myrde processer i cyklen, indtil den er brudt. Hvis der er flere af en type resurser, kan man også slå andre processer ihjel for at cyklen kan blive brudt. Gode processer at slå ihjel er de som kan starte forfra uden problemer fx en compiler. De to algoritmer gennemgås ikke, med mindre spurgt om En resurse pr type. Altså en printer, én CD-ROM. Vi kan enten modellere en graf over alle resurserne og deres requests, og på den må visuelt se om der er nogen cykler. Men for at vi kan gøre det automatisk har vi selvfølgelig også brug en algoritme. Vi har en datastruktur, L, der indeholde noder og pile. Pilene vil under algoritmen blive markeret som inspiceret. Algoritmen tage alle nodes, og vha. en dybde-først søgning, håber på at kunne lave en træstruktur. Hvis den på et tidspunkt kommer til sig selv igen, er der en cykel. For hver node, N, udfør disse 5 steps, med N som startnode: 1 Opret L uden nodes, og med pile umarked 2 Tilføj nuværende node N til L; tjek om N fremkommer dobbelt; hvis den gør er der en cykel, og vi terminerer 3 Hvis der nogen outgoing unmarked pile gå til sted 4; ellers gå til step 5 4 Vælg en tilfældig pile og følg den; marker denne pil 5 Hvis denne node er startnoden er der ingen cykler; ellers er vi kommet til en blind vej; slet noden og gå tilbage hvor du kom fra; gå til step 2 Flere resurser pr type. Page 29

30 For flere resurser skal vi have gang i et par vektorer og et par matricer: E er antallet af resurser i eksisens. Her fx 2 printere. A er antallet af resurser avalible. Her fx 1 printer. C er current allocation. Row = en process, og hver indgang svarer til om den allerede har en af en given resurce. Her har process 2, 2 stk. tape drivers og et CD drev R er request. Dvs hvad en given process mangler for at terminere. Her mangler process 2, 1 tape drive og 1 scanner. Algoritmen går ud på at vi ser om de nuværende resurser er nok til at få en process til at køre til sin død; hvorefter den kan release sine resurser for the greater good. 1 Vi tager vores vektor A og ser om der er en process der skal bruge dé eller færer recurser (aka om hver ingang i R(equest) er = A(valible) ) 2 Hvis der er det, markerer vi denne process (den kan altså køre til enden), og de resurser som den holdte (fra C) lægges oven i A. 3 Og så starter vi forfra i algoritmen. Hvis den kører færdig, og alle ikke er marked, er de processer deadlocked Deadlock avoidance, Banker s Algorithm Dynamsik detection ud i fremtiden. Vi laver en resursergraf og træffer nogle intelligente valg om hvem vi lader køre. Her går vi ud fra at ikke alle resurser bliver requested på én gang (som i vores R matrice), men én ad gangen. Når vi går ud fra det, er der så en algoritme der hele tiden træffer det sikre valg når den skal dele resurser ud? og svare er vist ja. Og det er den vi kalder Bankers algorithm. Page 30

31 Resource Trajectories (Tegn først én resurse på, og sig at den fint kan avoides (pga coffman 2), tegn herefter den næste på, og sig at man skal undgå det hul der bliver skabt) Bankers algoritme Som deadlock detection, men hvor vi arbejder med safe og unsafe states. en safe state er hvor vi kan blive ved med at give resurser til processerne, hvorefter de kører færdig, og releaser resurser, som vi igen kan give videre; and so on, indtil alle processer er færdige Deadlock prevention Statisk analyse og prøv at fjen én af Coffmans betingelser Page 31