Scheduling 1 Niels Olof Bouvin Institut for Datalogi Aarhus Universitet
Tråde og deres indbyrdes forhold Sidste gang så vi på, hvorledes tråde kan skabes, og hvordan man kan skifte imellem dem I dag ser vi på, hvordan man deler computerens resourcer på en fair måde 2
yield() yield() { outgoing = current; next = choosenextthread(); current = next; // so the global variable will be right switchfromto(outgoing, next); } choosenextthread()? Hvordan vælger den næste rigtige tråd til at køre på CPUen? 3
Oversigt Formålet med scheduling Trådes tilstande Fast prioritet Dynamisk prioritet Proportionel prioritet 4
Formålet med scheduling Med scheduling bestemmes den orden, hvori tråde afvikles på en eller flere CPUer Kan det gøres optimalt? Well, definér optimalt - udnytter de tilgængelige resourcer maximalt? - sikre, at computeren vedbliver responsiv? - sikre, at ingen jobs forbigås urimeligt? - sikre, at vigtige jobs klares først? 5
Tilgængelig information Udover en tråds øjeblikkelige tilstand, hvad kan vi så vide om et job? - hvor vigtigt er det? - og hvad mener vi med vigtig? - venter den på noget, og i givet fald på hvad? - forventet køretid: hvor længe kørte det sidste gang? 6
Oversigt Formålet med scheduling Trådes tilstande Fast prioritet Dynamisk prioritet Proportionel prioritet 7
Trådes tilstand Initiation yield or preemption Enten Runnable - arbejder en tråd ( running ) - har en tråd arbejde, som den kunne lave ( runnable ) - eller også venter den på noget ( waiting ) Runnable/waiting tråde dispatch Waiting - venter i køer/lister/træer ofte sorteret efter en prioritet eller deadline 8 event wait Running Termination
Omkostningen ved trådskift Det er ikke gratis at skifte fra én tråd til en anden - der skal gemmes registre, SP, IP, mv på stakken - og der er langt ud til hukommelsen fra CPU målt i nanosekunder - herudover har en tråd data gemt lokalt i CPUens cache RAM - sandsynligvis værdiløs for den næste tråd, der skal hente sin data CPU affinity holder tråde på samme core 9
Oversigt Formålet med scheduling Trådes tilstande Typer af schedulering Fast prioritet Dynamisk prioritet Proportionel prioritet 10
Simpel schedulering: Round Robin Ved hjælp af en hardware interrupt timer opdeles tiden på en CPU i intervaller - f.eks. 5 ms Alle (runnable) tråde skiftes, efter tur, til at køre på CPUen i et interval - alle tråde deles ligeligt om CPUen; alle får adgang - vigtige såvel som mindre vigtige jobs behandles ens - er der mange tråde, kan ventetiden blive lang 11
Arbejdsprofiler for computere Kontrol og styring - indbyggede systemer. Hårde tidskrav jobs skal gøres Servere - mange jobs, dyre maskiner. Udnyt resourcer maximalt. Throughput er essentielt. Personlige computere - ofte relativt lavt arbejdspres det meste af tiden. God brugeroplevelse i fokus lav responstid er essentiel 12
Urgency, Importance & Resource Allocation Presserende - er der en snarlig deadline for jobbet? Vigtighed - hvor vigtigt er jobbet i forhold til andre job? Resourcedeling - hvor stor del af de tilgængelige resourcer bør et job have? 13
Oversigt Formålet med scheduling Trådes tilstande Typer af schedulering Fast prioritet Dynamisk prioritet Proportionel prioritet 14
Fast prioritets schedulering Koncept: Tildel tråde en prioritet og foretræk altid højstprioriterede tråde - simpelt: prioriteterne sættes og kan let checkes - når CPUen bliver ledig, start højeste, runnable tråd - hvis ny runnable tråd har højest prioritet, startes dén Fare: Miskonfigurér prioriteterne, og en høj prioritetstråd kan sulte resten af systemet 15
Realtidssystemer Involverer ofte tråde givet opgaver med kendt worst-case performance og faste, periodiske deadlines Liu/Layland teoremer for fast prioritet: - hvis deadlines kan overholdes, vil de overholdes i et system, hvor de korteste perioder prioriteres - det er tilstrækkeligt at undersøge worst case, hvor samtlige trådes periode starter ved 0 16
Et eksempel på et problem T1 T1 - worst case: 2 s - periode: 4 s - højeste prioritet T2 T2 - worst case: 3 s - periode: 6 s - laveste prioritet 0 1 2 3 4 5 6 7 8 9 10 11 12 T1 T2 T1 - Ved tid 6 har T2 kun kørt 2 s, og har da overtrådt sin deadline. Systemet har derfor fejlet. 17
Fast prioritet Simple, hurtige, ikke resourcekrævende Lette at analyse Ufleksible Sårbare, så skal bruges med forsigtighed og omtanke Typisk kún brugt under særdeles kontrollerede forhold 18
Oversigt Formålet med scheduling Trådes tilstande Typer af schedulering Fast prioritet Dynamisk prioritet Proportionel prioritet 19
Dynamisk prioritet Faste/statiske prioriteter er for ufleksible, og kræver nøje planlægning fra starten Operativsystemet kunne måske i stedet for dynamisk ændre trådes prioritet efter behov? Dette ville gøre schedulering mere robust 20
Earliest Deadline First Den højeste prioritet tildeles den runnable tråd, hvis deadline er nærmest T1 T2 0 1 2 3 4 5 6 7 8 9 10 11 12 T1 T2 T1 T2 T1 T1 T2 T1 T2 T1 T2 21
Personlige computere De fleste operationer på en personlig computer er typisk ikke karakteriseret ved hårde deadlines - undtagelser inkluderer: lyd- og videoafspilning Der giver det mere mening dynamisk at styre prioritet efter - hvor vigtig jobbet er for brugeren - således at responstid er så god som mulig 22
Schedulering på Windows Prioriteter ændres dynamisk Når en tråd bliver runnable - hæves prioriteten initielt, så tråden foretrækkes - prioriteten falder (linært), mens tråden kører Prioriteten kan hæves forskelligt - interaktive tråde hæves mere end simpel I/O Brugeren kan angive vigtighed af jobs 23
Usage decay scheduling (OS X) Jo længere en tråd har kørt (jo højere usage), des lavere prioritet får det (til en vis grænse) - når tråden ikke kører, falder dens usage med tiden til nul En tråd, der ikke har kørt i et stykke tid, får sin prioritet opjusteret til basisniveauet Usage Priority Base priority Time Time 24
Usage decay scheduling Med UDS opnås, at tråde, der venter på input, får opjusteret deres prioritet, således, at de, når input bliver klar, hurtigt får tildelt processortid Dette sikrer en høj grad af interaktivitet Ved at sænke kørende trådes prioritet under basisniveauet, sikres at selv lav prioritetstråde bliver kørt fra tid til anden 25
Ulemper ved dynamisk prioritet Denne type schedulering er velegnet til at sikre et responsivt system Men præcis styring er vanskeligere - det er ikke det primære mål (og der er jo typisk maskinkraft nok til, at jobs bliver udført alligevel) - der er almindeligvis tale om enkel bruger maskiner 26
Energiovervejelser ved schedulering Schedulerings hjerteslag er I/O og tidsbestemte events - de enkelte tråde arbejder og sover i forskellige intervaller En kørende CPU bruger strøm - men kan bringes i sleep state (meget mindre strømforbrug), når der ikke er noget at lave - dette er vigtigt for batterilevetiden 27
Mac OS X: Timer Coalescing De enkelte tråde tvinges kører, når i geled det passer dem - dette der er giver næsten CPUen hele mulighed tiden arbejde for at til sove CPUen spare strøm 28
Oversigt Formålet med scheduling Trådes tilstande Typer af schedulering Fast prioritet Dynamisk prioritet Proportionel prioritet 29
Proportionel scheduling Det kan ofte give mening at kræve, at en tråd (eller et job eller en bruger) skal tilordnes en bestemt andel af de tilgængelige resourcer - måske skal man dele ligeligt mellem brugerne - måske har én bruger betalt mere end de øvrige Der bliver dynamikken fra UDS besværlig 30
Metoder til at sikre proportion 0 5 10 15 20 25 30 T1 T2 T3 Weighted Round-Robin - hver tråd kører lige ofte. De privilegerede tråde kører længere af gangen end mindre privilegerede tråde Weighted Fair Queuing 3: T1 2: T2 1: T3 - alle tråde kører et bestemt tidsrum. Privilegerede tråde kører oftere end mindre privilegerede tråde T1 T2 T3 T1 T2 T1 31
nice i Linux Niceness bruges til at angive, hvor vigtig en tråd er Den højeste værdi er -20 (mindst nice) Den laveste værdi er 19 (mest nice) Standardværdien er 0 Intuition: Jo flinkere en tråd er, jo mindre tid får den - (!) 32
Completely Fair Scheduling En variant af Weighted Round-Robin, som bruges i Linux Tråde tildeles en vægt baseret på deres niceness weight = 1024 1.25 nice Tråde tildeles derefter tid proportionalt til deres vægt i forhold til den samlede vægt 33
CFS target tid Target tid: Det tidsrum, hvorefter alle runnable tråde har kørt. Konfigurérbar. 6 ms på en enkel core maskine - hvis der er mange tråde, justeres target op Hvis alle tråde har samme niceness, har de samme vægt, og dermed deles de ligeligt om den tilgængelige tid - så bliver det en standard round robin algoritme 34
CFS vægt eksempel To tråde T1 & T2 med niceness 0 hhv. 5 T1 s vægt er T2 s vægt er b 1024 1.25 0 c = 1024 b 1024 1.25 5 c = 335 T1 s proportion bliver T2 s proportion bliver 1024 1024+335 0.75 335 1024+335 0.25 Med target tid på 6 ms, kan vi derfor forvente, at T1 får 4.5 ms og T2 får 1.5 ms 35
Virtual runtime Linux tæller, hvor lang tid den enkelte tråd har kørt, skaleret i forhold til trådens vægt Således ville T1 blive krediteret for at have kørt 1 ns per faktisk kørt nanosekund, hvor T2 ville blive krediteret 3 ns for samme tid - dette kaldes virtual runtime Linux vælger den (runnable) tråd, der er længst bagud (har mindst virtual runtime) Lav vægt man kommer hurtigere foran 36
Akkumuleret virtual runtime 9 Virtual runtime for T1 og T2 Virtual runtime 6 3 0 Faktisk CPU tid: 0 3 6 9 12 T1 T2 Tid Da T2 har tre gange så lav vægt som T1, vokser dens virtual runtime tre gange hurtigere 37 T1 T1 T2
Opvågnende og nye tråde En tråd, der har ventet længe, sættes til en virtual runtime lidt lavere end laveste værdi - så kan den behandle sit input hurtigt En ny tråd får tildelt en virtual runtime lidt større end laveste værdi - den kommer snart i gang, men ikke på bekostning af de mest trængende - dette hjælper også på Denial of Service angreb 38
CFS Med niceness kan en system administrator styre prioriteringen af de kørende programmer Ved at give tråde, der har ventet på input, en (lidt) lavere virtual runtime, gøres systemet responsivt 39
Sammenfatning Scheduling afhænger af brugskontekst - Realtidssystemer opererer med hårde tidsgrænser - Serversystemer værdsætter høj throughput - Personlige systemer prioriterer responstid Typisk har et moderne operativsystem elementer af alle tre typer 40