gef 435 principes des systèmes dexploitation ordonnancement pt ii (tanenbaum 2.5)

GEF 435Principes des systèmes d’exploitation

Ordonnancement Pt II(Tanenbaum 2.5)

Revue

• Quand est-ce que l’on prend des décision d’ordonnancement?

• Quels sont les buts de l’ordonnancement pour les systèmes interactifs

Synopsis

• Ordonnancement des systèmes interactifsRound-Robin – Tourniquet (Chacun son tour)Basé sur prioritéLe processus le plus court en prochainOrdonnancement garanti*Ordonnancement de loterie Ordonnancement équitable

• Ordonnancement des systèmes en temps réel• Synthèse générique de l’ordonnancement

*Pas une garantie

Ordonnancement des systèmes interactifs

• Quelqu’un en quelque part est assit à un clavier et entre de l’information

• On se rappelle de nos objectifs:Temps de réponse rapideProportionnalité (Les choses que les usagers pensent qui

devraient prendre peu de temps; le devraient)

• Tout les algorithmes pour les systèmes interactifs peuvent être utilisés dans les systèmes de lots

• Pour les systèmes interactifs, notre cours est seulement concerné avec l’ordonnancement du CPU


• Ordonnancement de tourniquet (Round-Robin)Chaque processus ce voit assigné une unité de temps

qui s’appelle un quantumSi le processus est encore en train d’exécuter à la fin de

son quantum, le CPU est donné à un autre processusSi le processus bloque ou finit avant la fin de son

quantum le CPU est immédiatement réassignéChaque processus a le CPU à son tourSeul décision d’implémentation : combien de temps est

assigné pour un quantum?


• Ordonnancement de type tourniquet Combien de temps dans un quantum?

• Le changement de processus prend du temps: sauve/charge les registres et la mappe de mémoire (MMU), les tables de mise à jour, vidage et chargement de la cache, pagination, etc...

• Pour un changement de contexte qui prend 1ms combien de temps devrait être dans un quantum? Considérez l’overhead:

Longueur du quantum

1ms 4ms 10ms 20ms 50ms

Overhead 50% 20% 9.1% 4.8% 2%


• Ordonnancement du type tourniquetUn autre justification pour un quantum plus large: Si le

quantum est plus grand que la rafale moyenne de CPU les programmes vont bloquer plus souvent qu’ils sont préemptés Moins de temps de système (overhead) et pertes

Si les quantums plus grands sont mieux, pourquoi pas 100ms?• Que ce passerait t’il si 10 utilisateurs frappent une clef en même temps?

• Attente longue: le dernier utilisateur pourrait avoir à attendre 1 seconde avant de voir son caractère sur l’écran

Bon compromis: 20 à 50ms ou à peu près (cependant cet estimé est dépendant du système...)


• Ordonnancement par prioritéComme dans C/OS-II,

certains processus sont plus égales que d’autres…


• Ordonnancement par prioritéBasé sur les utilisateurs: Si nous partagions un

mainframe alors l’ordre des priorités pourrait être: Dr Beaulieu, Capt Bob, étudiants GEF 435, étudiants 245,…

Basé sur les processus: même sur un PC avec utilisateur unique il va y avoir des processus multiples. Qu’est-ce qui est plus prioritaire: le mouvement de la souris ou envoyer les courriels?


• Ordonnancement par priorités: Comment est-ce que l’on assigne les priorités?Statiquement: eg: chaque processus qui est créé par un

processus à priorité ‘X’ se voit assigné la priorité ‘X’Dynamiquement: Réagit pour donner au processus

interactifs une priorité accrue• Met la priorité à 1/f où f est la fraction du dernier quantum

qu’un processus a utilisé ... les commandes courtes font qu’un processus a une plus haute priorité


• Ordonnancement par priorité: combien de temps on va laisser les processus exécuter? Quelques choix:À jamais jusqu’à ce que un processus de plus haute

priorité arrive comme dans C/OS-IIPour un quantum, potentiellement plus de quantums

donnés aux processus à plus hautes prioritésDiminue la priorité d’un processus chaque tic d’horloge

jusqu’à ce que sa priorité soit plus basse qu’un autre processus (ie: on avance vers les processus de plus basse priorité)

Ordonnancement des systèmes interactifs• Ordonnancement par priorité: hybride avec Round-

RobinAvoir Round-Robin dans chaque groupe de priorité et

exécute seulement les processus dans le groupe le plus haut• Problème: Les processus avec les priorités les plus basses peuvent

subir une famine...


• Le processus le plus court le prochainContrairement à plusieurs systèmes de lots, dans un système

interactif nous ne savons pas combien de temps va prendre la prochaine commande d’un utilisateur

On traite chaque commande comme un job, et on estime le temps que la prochaine commande va prendre basé sur le travail précédent mais on “age” les commandes plus vielles:

• Si on a l’estimé courrant pour la prochaine commande, T0, et que notre prochaine exécute dans le temps T1, alors notre nouvel estimé est T0/2 + T1/2

• Après deux commandes de plus l’estimé serait...?

• T0/8 + T1/8 + T2/4 + T3/2


• Ordonnancement garantiChaque processus recevra 1/n du CPU quand il y aura n

processus actifsCeci requiert que les temps d’utilisation du CPU pour

chaque processus soient traqués et ajustés pour faire certain qu’un processus n’ait pas plus de temps que les autres

Ne soyez pas confus par le nom, cette méthode ne garantie pas l’ordonnancement à un temps particulier

Problème: difficile de rencontrer cette promesse et cela prend du temps à faire...


• Ordonnancement par loteriePrincipe: Donne des billets et tire en un au hasard pour

voir quel processus exécute• Le grand prix: le temps du CPU

Avantages:• Bon temps de réponse: un nouveau processus a une chance

d’être ordonnancé à partir du début de sa vie

• Billets multiples peuvent être donnés pour arranger la fraction de temps du CPU

• Les processus qui coopèrent peuvent se donner des billets pour améliorer les chances d’exécution


• Ordonnancement équitable (Fair-Share)Cette méthode fait certain que chaque utilisateur obtient sa

part équitable au lieu de chaque processusSi je démarre la calculatrice, Word, PowerPoint, et que

j’exécute un programme web, est que j’obtiens 4x plus de temps de CPU qu’un utilisateur avec un seul processus?

Dans ce modèle chaque utilisateur a un pourcentage du CPU qu’il divise entre ses processus

• ie: Chaque processus a 50%. Utilisateur 1 a les processus ABCD et Utilisateur 2 a le processus E. Si ils utilisent tout le temps du CPU, alors l’ordre sera: AEBECEDEAEBE...

Ordonnancement des systèmes en temps réel


• Dans un système à temps dure (tolérance zéro), les deadlines doivent être rencontrés ou une catastrophe peut arriver

• Dans un système à temps mou, certains deadlines peuvent être manqué mais pas désirable

• Les événements peuvent être ou bien périodiques ou apériodiques

• Être capable de déterminer si il est possible pour un système en temps réel de rencontrer ses deadlines est le sujet d’autres cours et beaucoup de recherche, mais…


•Si il y a m événements périodiques sur un système, chacun demandant C secondes de temps de CPU et ayant la périodicité P, considérez:

Il est évident que si l’équation n’est pas satisfaite, il y a plus de travail à faire que le CPU peut prendre et les deadlines ne seront pas rencontrés le système n’est pas « ordonnançable »

Sujets divers dans l’ordonnancement


• Politique vs. MécanismeNotre discussion de l’ordonnancement a assumé des

processus en compétition pour le CPU avec différents buts et probablement différents propriétaires

• Que ce passe t’il dans un système en temps réel où les processus coopèrent?

• Que ce passe t’il pour un processus qui possède plusieurs threads enfants qui veulent travailler ensemble?

Processus/threads qui travaillent ensemble peuvent bénéficier en séparant la politique de décisions du mécanisme qui applique les politiques


• Politique vs. MécanismeDans cette configuration il y aura des temps où les

processus peuvent spécifier leur politique d’ordonnancement et l’ordonnanceur implémente cette politique

• Exemple: Donner un appel de système où les processus peuvent changer les priorités de leurs enfants. Alors un processus décide la politique et l’ordonnanceur devient le mécanisme pour donner le CPU en accordance avec la politique


• Ordonnancement des threadsOn se souvient que les threads peuvent être

ordonnancés dans le noyau ou dans l’espace utilisateur


• Ordonnancement des threadsUn ordonnanceur au niveau du noyau va être plus lent (à cause

des traps au noyau) mais on doit considérer qu’en général, changer de thread est plus vite que changer de processus

Un ordonnanceur dans l’espace de l’utilisateur sera plus efficace mais plus compliqué et il bloquera tout les threads durant un appel de système

Pour décider lequel utilisé et comment l’employer est une question de compromis

• C’est du design

Quiz Time!

Questions?

gef 435 principes des systèmes dexploitation ordonnancement pt ii (tanenbaum 2.5)

Documents