Realtidsstöd i Minix. En laborationrapport. Oktober 2012

Transkript

1 Realtidsstöd i Minix En laborationrapport Karl Zylinski Hampus Gustafsson Oktober

2 Innehåll 1 Introduktion Problem Skapa ett testprogram Se till att varje process känner till sitt realtidskrav Lägga till systemanrop vars syfte är att sätta deadline Förändra Minix schemaläggare så att den prioriterar processer med realtidskrav Utförande Skapa ett testprogram Se till att varje process känner till sitt realtidskrav Lägga till systemanrop vars syfte är att sätta deadline Förändra Minix schemaläggare så att den prioriterar processer med realtidskrav Analys Vår utökade schemaläggare Program och processer Appendix A: Kod tillagd i Minix kärna och tjänster kernel/proc.h servers/pm/table.c servers/pm/proto.h servers/pm/misc.c include/minix/com.h kernel/system.h kernel/system.c kernel/system/do setdl.c include/minix/callnr.h lib/posix/ setdl.c lib/posix/makefile.in kernel/system/do fork.c kernel/main.c kernel/proc.c Appendix B: Användarprogram deadline.c deadlinetest.c

3 1 Introduktion Detta är en rapport som beskriver och diskuterar utförandet av en laborationsuppgift i kursen operativsystem vid Högskolan i Skövde. Det är således en väldigt teknisk rapport och kunskap om såväl operativsystem som programmering är nödvändigt för att ta till sig innehållet. Rapporten består av fyra delar; Den introduktion du just nu läser, som även inenhåller en problembeskrivning, en huvuddel som beskriver vilka val som gjordes och hur arbetet utfördes, en resultat-del där bland annat körexempel demonstreras samt en reflektiv analys-del. Det finns även en appendix-del i slutet där all kod som lagts till eller ändrats går att finna. 1.1 Problem Vårt problem var undersöka hur realtidsstöd i Minix skulle gå att tillhandahålla genom att utöka kärna och tjänster samt på detta vis tillhandahålla detta. Realtidsstödet skulle realiseras genom att ge användare av operativsystemet en möjlighet att sätta en deadline för processen. Under nedanstående rubriker delas uppgiften upp i flera delproblem och deluppgifter Skapa ett testprogram Uppgiftsbeskrivningen inkluderade ett komplett exempelprogram (deadline.c, 5.1, sidan 12) som varje sekund satte deadline till en sekund. Om denna deadline missades så stängde programmet av sig och skrev ut ett felmeddelande. Om programmet under 100 sekunder lyckades hålla alla deadlines så skrevs ett meddelande ut och varpå det avslutades. Detta program använde sig av en icke-existerande biblioteksfunktion vid namn setdl för att sätta sin deadline. En av våra deluppgifter var att se till att denna funktion existerar och att den sätter deadline för processen. Enligt uppgiften skulle realtidsstödet testas genom att starta flera samtida ovan beskrivna exempelprogram och se till att samtliga håller sin deadline. Utan realtidsstödet så klarade sig på vår hårdvara maximalt 8 program, vi skulle se till att minst 15 program klarade kravet. En av deluppgifter var således att skapa ett program som startar flera exempelprogram och väntar på att de kör klart, detta program kallas hädanefter för testprogrammet Se till att varje process känner till sitt realtidskrav För att kunna sätta en deadline på en process så måste en process på något vis kunna ta emot och spara undan denna deadline. Detta krävde alltså att vi på något vis skulle förändra den datastruktur som representerar processtabellen och införa en representation av deadline. 3

4 1.1.3 Lägga till systemanrop vars syfte är att sätta deadline Eftersom vårt exempelprogram ville sätta sin deadline med en icke-existerande biblioteksfunktion setdl var vi tvungna att lägga till denna funktion. Denna funktion skulle i sin tur vara kopplad till ett systemanrop från användarrymd till servicerymd. Servicerymd-funktionen skulle i sin tur vara kopplad från servicerymd till kärnrymd. I kärnrymden skulle processtabellen modifieras och vår nya deadline sättas Förändra Minix schemaläggare så att den prioriterar processer med realtidskrav Det sista steget i laborationen var att förändra systemets schemaläggare. En schemaläggare är ansvarig för att bestämma vilken process som skall få CPUtid härnäst. Vanliga problem med schemaläggning är svält, att en process aldrig får CPU-tid eftersom algoritmen konstant bestämmer att andra processer skall få CPU-tid. Det finns många olika algoritmer för att göra detta, Minix använder sig av en algoritm som kallas Multilevel Feedback Queue Scheduling som väldigt väl undviker svält. Algoritmen bygger på en round-robin algoritm, en sådan algoritm går igenom alla processer och ger alla processortid. Processerna är tilldelade ett tidskvanta, överskrids detta så byter processorn till nästa process i kön. Utöver detta delar algoritmen in processerna i cirka 15 olika köer där varje kö representerar en prioritetsnivå, då en process missar sitt tidskvanta så bestraffas den genom att nedprioriteras. Prioritetsnivån med högst värde är de lägst prioriterade kön, den med lägst värde är det högst prioriterade. Minix schemaläggare är på grund av detta väldigt rättvis. Det är en del av problemet med uppgiften, det vill säga att förändra en väldigt rättvis schemaläggare så att den favoriserar processer med en deadline och därmed realiserar realtidskravet. Det är också viktigt att processer med en deadline inte bestraffas då överskrider tilldelat tidskvanta. 2 Utförande Här beskrivs under samma rubriker som problem-avsnittet (1.1, sida 3) hur vi gick till väga för att lösa problemen. 2.1 Skapa ett testprogram Vårt testprogram är väldigt enkelt. Det loopar ett antal gånger och skapar för varje varv i loopen en ny process som startar en instans av det program som angivits som parameter (förmodligen exempelprogrammet). Programmet väntar innan det avslutas på de processer som tidigare startats. Källkoden för detta program finns i avsnitt 5.2 på sidan 13 (deadlinetest.c). 4

5 2.2 Se till att varje process känner till sitt realtidskrav För att ge en process kännedom om sitt realtidskrav så behövde vi lägga till en variabel för detta i dess Process Control Block. Detta är den datastruktur där information nödvändig för kontext byten, schemaläggning och dylikt finns. I Minix så är detta en struct som innehåller ett antal variabler som håller reda på saker som prioritet, kvarvarande tidskvanta (för fair-share schemaläggningen) och minneslayouten för text, stack och kod. Vi lade längst ner i Process Control Block, i proc.h, till en variabel av typen long vid namn p_deadline. Vi valde typen long och inte int eftersom den måste kunna lagra lika stora tal som systemklockan. Tanken är då en deadline sätts så adderas nuvarande systemtid till hur lång deadline som angivits, det slutgiltiga klockslaget lagras sedan i p_deadline. 2.3 Lägga till systemanrop vars syfte är att sätta deadline Exempelprogrammet anropar en biblioteksfunktion vid namn setdl, denna funktionen saknas och vi var därför tvungna att lägga till den i Minix POSIXbibliotek. Funktionen ser vi i figur 1. PUBLIC int s e t d l ( int d e a d l i n e ) message m; m. m1 i2 = d e a d l i n e ; return ( s y s c a l l (MM, SETDL, &m) ) ; Figur 1: Vår implementation av setdl Funktionen skapar ett nytt meddelande och lagrar deadline i ett av meddelandets medlemsvariabler. Därefter görs själva systemanropet till servicerymd och processhanteraren. SETDL är i vår implementation definierad till 67, detta är alltså index i processhanterarens avbrottsvektor. Notera att det är möjligt att från användarrymden skriva _syscall-raden direkt, det är dock mer intuitivt att tillhandahålla en biblioteksfunktion. I processhanteraren tas sedan detta systemanrop emot av funktionen do_- setdl i processhanteraren, som är knuten till avbrott nummer 67/SETDL, funktionen ser vi i figur 2. Det enda funktionen gör att ta emot det meddelande vi i tidigare steg skapade varpå det lägger till endpoint-värdet från processhanterarens processtabell. Endpoint är för vare process ett unikt värde som identifierar processen, detta värde kan kärnan översätta till ett för kärnan användbart processnummer. Anledningen till att endpoint behövs är att kärnan och processhanteraren har olika stora tabeller eftersom processhanteraren inte känner till kärnans processer. Meddelandet skickas därefter vidare till kärnan med hjälp av ett så kallat taskcall, det vill säga ett anrop till kärnan. 5

6 PUBLIC int d o s e t d l ( ) m in. m1 i1 = mp >mp endpoint ; t a s k c a l l (SYSTASK, SYS SETDL, &m in ) ; return (OK) ; Figur 2: Funktionen do setdl i processhanteraren #include.. / system. h #include <s t d i o. h> #include <c l o c k. h> PUBLIC int d o s e t d l ( m ptr ) register message * m ptr ; struct proc * proctab ; int p proc ; /* T r a n s l a t e endpoint to p r o c e s s number */ i f (! i s o k e n d p t ( m ptr >m1 i1, &p proc ) ) return EINVAL; /* Get p r o c e s s t a b l e a d r e s s f o r p r o c e s s number p proc */ proctab = proc addr ( p proc ) ; /* Error i f p r o c t a b i s empty */ i f ( isemptyp ( proctab ) ) return EINVAL; i f ( m ptr >m1 i2 == 0) proctab >p d e a d l i n e = 0 ; else proctab >p d e a d l i n e = get uptime ( ) + m ptr >m1 i2 ; return (OK) ; Figur 3: Vårt taskcall (anrop till kärnan) som hittar processen med hjälp av endpoint och sätter deadline för funnen process För att skapa ett nytt taskcall måste vi först ge anropets avbrott ett unikt värde. Detta görs i filen com.h (4.5, sida 10). Därefter skapade vi en ny funktionsdeklaration i system.h (4.6, sida 10), denna funktion kopplas sedan samman med det avbrottsnumret med hjälp av funktionen map som vi ser i filen system.c (4.7, sida 10). Efter detta kunde själva implementationen av vårt taskcall skrivas, vilket visas i figur 3. Vi översätter från endpoint (lagrad i m_ptr->m1_i1) till ett processnummer med hjälp av funktionen isokendpt, därefter använder vi processnumret för att hämta ut pekaren till korrekt processtabell, vilket görs med funktionen proc_addr. Hittar vi med hjälp av dessa funktioner en korrekt 6

7 pekare till en processtabell så används sedan denna pekare till att sätta vår deadline, vi sätter helt enkelt värdet på p_deadline som vi tidigare lade till i alla processers tabell. 2.4 Förändra Minix schemaläggare så att den prioriterar processer med realtidskrav För att realisera realtidskravet så behöver processen först och främst ha hög prioritet, så att den hamnar i en av de högst prioriterade redoköerna. I Minix så är den högst prioriterade kön en användarprocess får använda satt till USER_Q, som vanligen är definierad till 7. Vi valde att helt enkelt tvinga in realtidsprocesserna i denna kö. Utöver detta behöver även processerna med realtidskrav sorteras efter deadline så att de med kortast deadline ligger först i kön. Alla förändringar vi gjorde av schemaläggaren gjordes i filen proc.c. En komplett lista av dessa förändringar finns i avsnitt 4.14 på sidan 11. Vi började med att i proc.c skapa en funktion vid namn is_rtp som kontrollerar om en process är av realtidstyp, i denna kontroll ingår att se till så att den inte är en process tillhörande kärnan samt att deadlinen inte har överskridits. Därefter förändrade vi funktionen sched enligt figur 4. sched är en funktion som anropas då processer skall läggas till i en redokö. Den bestämmer i vilken kö samt var i kön en ny process skall läggas. Vi lade i funktionen till en if-sats som särbehandlar processer som är av realtidstyp. Funktionen sätter för dessa processer prioriteten (som bestämmer vilken kö processen kommer hamna i) till USER_Q och återställer deras tidskvanta, så att processen aldrig får slut på tidskvanta. i f ( i s r t p ( rp ) ) rp >p p r i o r i t y = USER Q ; rp >p t i c k s l e f t = ; t i m e l e f t = 1 ; Figur 4: Våra förändringar i funktionen sched, den sätter för alla realtidsprocesser prioriteten till USER_Q (vanligen 7) samt återställer dess tidskvanta, så att detta inte kan överskridas Det enda som kvarstod efter detta var att se till så att realtidsprocesserna då de läggs till i en redokö (det vill säga kö nummer USER_Q) läggs till först i kön. Vi lade för detta till koden i figur 5 i funktionen enqueue. Det enqueue gör är att den med hjälp av sched lägger till processer på en korrekt plats. Standardbeteendet för enqueue och sched var det som beskrevs i på sidan 4. Det som lades till i funktionen var en if-sats som kontrollerar om processtabellen rp (pekare till den process som skall läggas till) är av realtidstyp, vilket gör med hjälp av funktionen is_rtp. Därefter hämtas en pekare till en pekare 7

8 register struct proc ** r t s o r t p ; i f ( i s r t p ( rp ) ) r t s o r t p = &rdy head [ q ] ; while (* r t s o r t p!= NIL PROC && (* r t s o r t p ) >p d e a d l i n e < rp >p d e a d l i n e ) r t s o r t p = &(* r t s o r t p ) >p nextready ; rp >p nextready = * r t s o r t p ; * r t s o r t p = rp ; i f ( rp >p nextready == NIL PROC) r d y t a i l [ q ] = rp ; else Figur 5: Våra förändringar i funktionen enqueue, den loopar för realtidsprocesser igenom vald prioritetskö tills den hittar en process med längre deadline än den som skall läggas till och lägger då före denna till processen. till huvudet i den redokö där processen skall läggas till ut (rt_sort_p). Denna variabel är en pekare till en pekare därför att vi vill kunna byta värdet på själva elementet i redokön, detta hade i en vanlig array gått att göra med ett index, men i en länkad lista finns det inga index. while-loopen i den tillagda koden loopar så länge rt_sort_p har en kortare deadline än processen vi vill lägga till, för varje varv i loopen tas nästa element i listan ut och rt_sort_p sätts till en pekare till en pekare till detta element. När loopen är klar har vi antingen funnit det första elementet med längre deadline än den process som skall läggas till alternativt nått slutet av redokön. Därefter sätts p_nextready för rp till det hittade elementet. Detta gör att det hittade elementet ligger efter rp i den länkade listan, därefter byter rt_- sort_p och rp plats med hjälp av raden *rt_sort_p = rp;. Elementet har nu lagts till på korrekt position i listan. Notera att p_nextready för rp kommer att vara NIL_PROC om loopen ovan fann slutet på listan, detta gör att den länkade listan nästan automatiskt får ett korrekt slut, vi behöver dock justera redoköns ände-variabel (rdy_tail) manuellt, vilket är det sista som görs i den tillagda koden. 3 Analys 3.1 Vår utökade schemaläggare Vår schemaläggare låter processer med kortare deadline gå före de med längre deadline, vilket är en simpel lösning som tyvärr kan skapa svält hos de processer som saknar deadline. En potentiell lösning till detta är att skapa en separat kö 8

9 för endast realtidsprocesser, hur mycket detta skulle hjälpa är dock osäkert med tanke på att processorn fortfarande måste gå igenom kön med realtidsprocesser innan den kan ta sig an övriga. 3.2 Program och processer Konceptet med program och processer är en viktig del att förstå i ett operativsystem. En process är till skillnad får ett program inladdat i minnet och kan därför köras på processorn. Ett program är alltså inte inladdat i minnet utan ligger inaktivt på sekundära minnet och har minst en exekveringstråd, stack, heap och programräknare. Fördelarna med algoritmen är att den är hyfsat snabb eftersom nya realtidsprocesser får rätt plats i kön utan att kön behöver sorteras separat och att den är ganska simpel. 4 Appendix A: Kod tillagd i Minix kärna och tjänster 4.1 kernel/proc.h Tillagt längst ner i struct proc long p d e a d l i n e ; 4.2 servers/pm/table.c Tillagt i tabellen d o s e t d l, /* 67 = s e t d l */ 4.3 servers/pm/proto.h Under /* misc.c */ lade vi till PROTOTYPE( int d o s e t d l, ( void ) ) ; 4.4 servers/pm/misc.c PUBLIC int d o s e t d l ( ) m in. m1 i1 = mp >mp endpoint ; t a s k c a l l (SYSTASK, SYS SETDL, &m in ) ; return (OK) ; 9

10 4.5 include/minix/com.h # define SYS SETDL (KERNEL CALL + 50) /* s y s s e t d l ( ) */ #define NR SYS CALLS kernel/system.h /* t a s k c a l l f o r s e t t i n g d e a d l i n e */ PROTOTYPE( int d o s e t d l, ( message * m ptr ) ) ; 4.7 kernel/system.c map(sys SETDL, d o s e t d l ) ; /* s e t d e a d l i n e */ 4.8 kernel/system/do setdl.c Ny fil #include.. / system. h #include <s t d i o. h> #include <c l o c k. h> PUBLIC int d o s e t d l ( m ptr ) register message * m ptr ; struct proc * proctab ; int p proc ; /* T r a n s l a t e endpoint to p r o c e s s number */ i f (! i s o k e n d p t ( m ptr >m1 i1, &p proc ) ) return EINVAL; /* Get p r o c e s s t a b l e a d r e s s f o r p r o c e s s number p proc */ proctab = proc addr ( p proc ) ; /* Error i f p r o c t a b i s empty */ i f ( isemptyp ( proctab ) ) return EINVAL; i f ( m ptr >m1 i2 == 0) proctab >p d e a d l i n e = 0 ; else proctab >p d e a d l i n e = get uptime ( ) + m ptr >m1 i2 ; return (OK) ; 4.9 include/minix/callnr.h #define SETDL 67 /* s e t d e a d l i n e f o r p r o c e s s */ 10

11 4.10 lib/posix/ setdl.c Ny fil #include <l i b. h> #include <u n i s t d. h> PUBLIC int s e t d l ( int d e a d l i n e ) message m; m. m1 i2 = d e a d l i n e ; return ( s y s c a l l (MM, SETDL, &m) ) ; 4.11 lib/posix/makefile.in s e t d l. c \ 4.12 kernel/system/do fork.c /* I n i t i a l i z e d e a d l i n e f o r p r o c e s s to 0 */ rpc >p d e a d l i n e = 0 ; 4.13 kernel/main.c rp >p d e a d l i n e = 0 ; 4.14 kernel/proc.c Bland deklarationerna högst upp i filen FORWARD PROTOTYPE( int i s r t p, ( struct proc * rp ) ) ; Längre ner i filen PRIVATE int i s r t p ( pr ) struct proc * pr ; return pr >p d e a d l i n e!= 0 &&! i s k e r n e l p ( pr ) && pr >p d e a d l i n e > get uptime ( ) ; I funktionen enqueue register struct proc ** r t s o r t p ; i f ( i s r t p ( rp ) ) r t s o r t p = &rdy head [ q ] ; 11

12 while (* r t s o r t p!= NIL PROC && (* r t s o r t p ) >p d e a d l i n e < rp >p d e a d l i n e ) r t s o r t p = &(* r t s o r t p ) >p nextready ; rp >p nextready = * r t s o r t p ; * r t s o r t p = rp ; i f ( rp >p nextready == NIL PROC) r d y t a i l [ q ] = rp ; else I funktionen sched i f ( i s r t p ( rp ) ) rp >p p r i o r i t y = USER Q ; rp >p t i c k s l e f t = ; t i m e l e f t = 1 ; 5 Appendix B: Användarprogram 5.1 deadline.c Testar under 100 sekunder hurvida ett program håller en deadline på en sekund #include <s t d i o. h> #include <s t d l i b. h> #include <u n i s t d. h> #include <s y s / types. h> #include <time. h> #include <s y s / r e s o u r c e. h> void t e s t r t ( void ) t i m e t r e c e n t ; t i m e t new ; int count ; int i n n e r ; s e t d l ( ) ; /* l e t a l l o t h e r RT p r o c e s s e s s t a r t up */ s l e e p ( 1 ) ; /* w h i l e we s l e e p */ r e c e n t = time (NULL) ; count = 0 ; while ( count < 100) s e t d l ( 6 0 ) ; /* s e t d e a d l i n e */ while ( ( new = time (NULL) ) == r e c e n t ) /* s t i l l on t h e same second */ /* do nothing */ 12

13 i f ( new == ( r e c e n t + 1) ) /* new second : did we s k i p any? */ count++; /* no s t i l l working in r e a l t i m e */ else /* missed t h e d e a d l i n e */ s e t d l ( 0 ) ; /* no l o n g e r r e a l time */ p r i n t f ( missed d e a d l i n e a f t e r %d seconds \n, count ) ; return ; r e c e n t = new ; s e t d l ( 0 ) ; /* no l o n g e r r e a l time */ p r i n t f ( s u c c e s s f u l l y met %d s u c c e s s i v e d e a d l i n e s \n, count ) ; int main ( int argc, char ** argv ) t e s t r t ( ) ; return 0 ; 5.2 deadlinetest.c Starta ett antal program med en deadline och vänta på att dessa skall köra klart. #include <u n i s t d. h> int main ( int argc, char ** argv ) int i = 0 ; p i d t pid = 1; char * newargv [ ] = l a x, NULL ; char * newargp [ ] = NULL ; for ( ; i <25; i ++) pid = f o r k ( ) ; i f ( pid == 0) execve ( argv [ 1 ], newargv, newargp ) ; else i f ( pid < 0) /* e r r o r */ return 1 ; while ( wait (NULL)!= 1) ; return 0 ; 13