Uke 11 - Scheduling, trap, systemkall og ticks, Dockerfiles

Oppgaver til mandag 10. - fredag 14. mars

  1. (Oblig)
  2. En trap instruksjon svitsjer modus for CPUen fra brukermodus til kjernemodus og hopper samtidig til kjernekode. Denne instruksjonen gjør det mulig at et program i burkermodus kan bruke funksjoner i operativsystemkjernen uten at man risikerer at brukerprogrammet tar over styringen.
  3. Hvis jiffie er veldig kort, vil det være en fordel for interaktive prosesser og responstiden som de opplever, siden det går kortere tid mellom hver gang OS er inne og sjekker need_resched og eventuelt switcher til interatktive prosesser. Ulempen med en veldig kort jiffie er at det blir mer overhead fordi prosessene blir oftere avbrudt.
  4. Hvis prosesser skal kunne kjøre direkte på CPU'en, kan de ikke tvinges til å avbryte for eksempel en evig løkke uten hjelp fra hardware . Timer-interruptet gjør at neste instruksjon er et hopp til kjernekode som gir OS kontrollen slik at det kan vurdere hvilken prosess som skal slippe til neste gang.
  5. Ved å variere størrelsen på antall jiffies som tildeles hver prosess(timeslice) vil noen prosesser prioriteres høyere enn andre ved at de får mer CPU-tid.
  6. (Oblig)
  7. (Oblig)
  8. (Oblig)
  9. Det vil være 30+20+10 = 60 timer-interrupts, ett for hvert tick, og to context switches som forklart i forrige delspørsmål.
  10. Når epoken er over tildeles nye ticks. Antall tick beregnes ut fra en grunntildeling (som blant annet avhenger av nice-verdi) og en dynamisk del som avhenger av hvor stor del av tildelte ticks som blir brukt opp. Brukes alle opp kan de ble tildelt færre ved neste epoke.
  11. En interaktiv prosess vil få mange ticks hver epoke og komme i en høy prioritetsklasse. Dermed vil den alltid velges før CPU-intensive prosesser etter en context switch. Men om ikke need_resched ble satt ved et interrupt fra for eksempel tastaturet, ville den interaktive prosessen som skulle hatt og prosessert dette tegnet måtte vente helt til en kjørende CPU-intensiv prosess var ferdig med alle sine tick i en epoke, før den slapp til etter en contex switch. At need_resched settes gjør at det skjer en context switch med en gang ved neste timer tick og interaktive prosesser får dermed en mye bedre responstid.
  12. Det er rimelig å anta at teksteditoren har høyest prioritet av de som ønsker å kjøre. Da vil det maksimalt ta en tick før tegnet vises på skjermen. Om det finnes kjerne-prosesser eller andre prosesser med høyere prioritet, vil disse normalt bruke lite CPU-tid før de avslutter eller selv venter på I/O, da vil tiden det tar kunne bli litt mer enn en jiffy. Tiden det tar vil øke proposjonalt med lengden på en jiffy. Vanligvis vil tegnet vises når neste tick inntreffer, i gjennomsnitt en halv jiffy.
  13. Om need_resched ikke brukes vil etter et trykk på tastaturet den CPU-intensive jobben bruke opp alle sine tick før det skjer en context og teksteditoren tar over. I snitt vil det derfor ta en halv timeslice = 50 ms. Hvis need_resched brukes, vil det i snitt ta en halv tick = 5ms.
  14. (Oblig)
  15. (Oblig)
  17. (Oblig)