Test et Optimisation des performances d`un scheduler sur un noyau

TEST ET OPTIMISATION DES PERFORMANCES
D'UN SCHEDULER SUR UN NOYAU LINUX 2.6.17
Jérôme Soumagne, Informatique, 2e année
Stage avec le Pr. Shigeru KUSAKABE
Dept. of Computer Science and Communication Engineering,
Grad. School of Information Science and Electrical Engineering,
Kyushu University
744 Motooka, Nishi-ku, Fukuoka-shi, 819-0395, Japan
Résumé
Les demandes récentes de service Internet entraînent une augmentation du nombre d'activités
concourantes devant être supportées par les applications de type serveur. Ainsi, un support
ecace du nombre de threads dans les systèmes d'exploitations est un objectif majeur dans le
domaine de l'Internet Computing. Des versions récentes du noyau Linux utilisent un sheduler
O(1) an
O(1) ne tient
en
de réaliser un ordonnancement ecace des threads. Cependant, le scheduler en
pas compte de l'anité des threads partageant le même espace d'adresse. A partir
du scheduler en
O(1),
un nouveau scheduler a été développé an d'augmenter les performances
des applications mutlithread de type serveur sur les plateformes Linux. Ce scheduler réunit les
threads qui partagent le même espace d'adressage, et peut exploiter le principe de localité, réduire
le coût des changements de contexte, et supporter un haut degré de concurrence.
Mots-clés
Système d'exploitation, Noyau, Scheduler, Multi-thread, Applications de type serveur.
1 Introduction
Les demandes récentes de service Internet entraînent une augmentation du nombre d'activités
concourantes devant être supportées par les applications de type serveur. Pour essayer, de contrer
ce phénomène, le laboratoire du Pr. Shigeru Kusakabe a développé un scheduler permettant
d'améliorer les performances pour des applications mettant en oeuvre un nombre important de
threads. Ce scheduler permet de diminuer le coût des changements de contexte en regroupant les
threads par espace d'adressage.
Dans une première partie, nous allons rappeler la structure de la runqueue présente dans le
noyau 2.6, pour voir ce qui a été ajouté par rapport à cette version. Enn, nous verrons dans
une dernière partie le travail devant être apporté à ce projet.
2 Le scheduler en O(1)
Pour comprendre l'intérêt d'utiliser un nouveau type de scheduler, voyons par un exemple
(gure 1) l'ordonnancement des threads qui se produit : dans le cas du scheduler classique cidessous, chaque processus runnable est ajouté dans la runqueue en fonction de sa priorité puis
est exécuté par ordre de priorité. Si l'on considère que les processus rouges et verts appartiennent
à des espaces d'adresse diérents, on a l'exécution suivante : A
eu trois changements de contexte lors de l'exécution.
1
⇒
B
⇒
C
⇒
D
⇒
E et on aura
Fig. 1 Runqueue du noyau 2.6
3 Le scheduler modié
Considérons maintenant la gure 2 : l'idée de ce nouveau type de scheduler est de créer une
runqueue auxiliaire par groupe de threads partageant le même espace d'adresse, cela, an de
diminuer le coût des changements de contexte. Alors que l'on avait une runqueue par processeur
ce qui entraînait des changements de contexte importants pour un même processeur, on peut ici
lier les runqueues auxiliaires à des processeurs diérents et ainsi éviter à un même processeur un
changement de contexte. Après ordonnancement, on a alors l'exécution suivante : A
⇒
B
⇒
⇒
C
⇒
D
E. On n'a ici plus qu'un seul changement de contexte (pour un même processeur, ou 0
si on a au moins deux processeurs).
4 Cahier des charges
Malgré cette apparente augmentation de performances, il s'avère que le scheduler présente
des instabilités (voir annexe A). C'est le thème de l'étude demandée par le Pr. Kusakabe.
Avant de débuter le travail de recherche de cette instabilité, une étude préliminaire sur le
fonctionnement du scheduler modié est nécessaire, ainsi que sur le développement du noyau
linux en général : les structures utilisées, les fonctions utilisées, ...
1
Le patch permettant de modier le scheduler du noyau 2.6 a été développé pour un noyau
2.6.17. Après récupération de ce noyau, application du patch, et recompilation, le premier objectif
2 telles que des applications de chat
3
room utilisant un grand nombre de threads ou bien Autobench , utilisant un serveur Apache,
est de mettre en oeuvre grâce des applications de benchmark
une batterie de tests an de mettre en évidence cette instabilité. (scripts, ...)
Le second objectif est de mettre en place une série de tests approfondis permettant de cibler
et de localiser l'origine des instabilités. Pour cela, il est nécessaire d'utiliser des applications de
monitoring telles que perfctr
4 . Il sera éventuellement nécessaire de modier le code du patch
Linux Kernel Development Second Edition
1
2 Page
3 Page
4 Page
, Robert Love, 2005
http://lbs.sourceforge.net
Autobench : http://www.xenoclast.org/autobench
Perfctr : http://user.it.uu.se/~mikpe/linux/perfctr/
de la Linux Benchmark Suite :
de
de
2
Fig. 2 Ajout de runqueues auxiliaires au noyau 2.6
pour pouvoir localiser l'origine de l'instabilité.
Le dernier objectif est la correction de cette instabilité. Ceci est naturellement le dernier
objectif mais également le plus dicile à atteindre.
A Instabilité du scheduler modié
Cette partie a seulement pour objectif de clarier et de rendre compte de l'instabilité du
scheduler modié, par conséquent, seule une partie des tests recueillis sont présentés dans cette
partie.
Les résultats ci-dessous (gures 3 et 4) ont été recueillis avec Autobench sur un processeur
Athlon 64 X2 3800+. Un serveur Apache est lancé en local et on crée des connexions. Ici, on a
500 connexions par test et on fait varier le taux de requêtes sur le serveur jusqu'à saturation du
serveur et on compare entre les versions patchées et non patchées du noyau 2.6.17.
D'après ces résultats, on voit ici très nettement le résultat de l'instabilité du patch appliqué
au noyau 2.6.17 : il n'y pas de réelle stabilisation lors de la saturation du serveur.
3
Fig. 3 Test avec Autobench sur le noyau 2.6.17
Fig. 4 Test avec Autobench sur le noyau 2.6.17-spa
4