- L’ordonnanceur CPU du noyau propose plusieurs modes de préemption qui mettent en œuvre un compromis entre le débit du système et le temps de réponse.
- En septembre 2023, lors d’une discussion sur l’ordonnancement, le concept de « préemption paresseuse » (
lazy preemption) a été proposé, avec l’idée qu’il pourrait offrir de meilleurs résultats tout en simplifiant l’ordonnancement du noyau.
- Le sujet est ensuite resté discret pendant un temps, avant de réapparaître avec une série de patchs de Peter Zijlstra.
Les modes de préemption actuels du noyau
- PREEMPT_NONE : la préemption n’est autorisée que lorsqu’une tâche en cours d’exécution a épuisé sa tranche de temps.
- PREEMPT_VOLUNTARY : ajoute de nombreux points dans le noyau où la préemption peut avoir lieu si nécessaire.
- PREEMPT_FULL : la préemption est possible à presque tous les points, sauf lorsqu’un spinlock est détenu.
- PREEMPT_RT : donne la priorité à la préemption par rapport à la plupart des autres considérations et rend préemptable l’essentiel du code utilisant des spinlocks.
Introduction de la préemption paresseuse
- Le patch de préemption paresseuse ajoute un nouveau drapeau
TIF_NEED_RESCHED_LAZY pour indiquer qu’un réordonnancement est nécessaire à un certain moment, mais pas immédiatement.
- Dans le mode de préemption paresseuse (
PREEMPT_LAZY), la plupart des événements définissent ce nouveau drapeau, et lors du retour du noyau vers l’espace utilisateur, l’ordonnanceur est appelé si l’un des deux drapeaux est défini.
- Avec ce changement, dans le mode de préemption paresseuse, la plupart des événements du noyau ne préempteront plus la tâche en cours.
Suppression de cond_resched()
- L’objectif final de ce travail est de ne conserver que deux modes non temps réel :
PREEMPT_LAZY et PREEMPT_FULL.
- Le mode paresseux se situe entre
PREEMPT_NONE et PREEMPT_VOLUNTARY, et remplace ces deux modes.
- À l’heure actuelle, les appels à
cond_resched() subsistent et restent nécessaires tant que les modes PREEMPT_NONE et PREEMPT_VOLUNTARY existent.
Le résumé de GN⁺
- La préemption paresseuse pourrait contribuer à simplifier l’ordonnancement du noyau et à fournir une latence plus prévisible.
- Ce travail pourrait aider à réduire la taille du noyau et à simplifier le code.
- La préemption paresseuse offre un débit similaire à
PREEMPT_VOLUNTARY, mais nécessite davantage de tests et d’optimisations.
- Parmi les autres projets dotés d’une fonctionnalité similaire figure l’ordonnanceur ULE de FreeBSD.
1 commentaires
Commentaires sur Hacker News
Le résultat final du travail sur la préemption paresseuse est que le noyau devient plus petit et plus simple tout en offrant une latence prévisible. Cela semble être une meilleure solution, sans avoir à disséminer des appels liés à l’ordonnanceur dans tout le code. Cependant, cela prendra du temps.
Un niveau élevé de préemption permet au système de réagir plus vite aux événements. Une réaction rapide à des événements comme un mouvement de souris ou un signal d’« effondrement imminent » d’un réacteur est plus satisfaisante. Cependant, un niveau élevé de préemption peut affecter le débit global du système. Les charges de travail comportant beaucoup de tâches intensives en CPU gagnent à être interrompues le moins possible. Une préemption plus fréquente peut entraîner une contention plus élevée sur les verrous. C’est pourquoi il existe différents modes, et le mode de préemption optimal dépendra sans doute de la charge de travail.
Le noyau actuel dispose de quatre modes qui contrôlent à quel moment une tâche peut être préemptée au profit d’une autre.
Je ne trouve pas de chiffres liés au patch dans le fil lié. Un benchmark préliminaire a sûrement été réalisé, qui pourrait donner une idée du potentiel réel de ce changement.
Je me demande à quel point l’ordonnanceur est étroitement couplé au reste du code du noyau.
Ce serait bien si la préemption pouvait s’adapter selon les événements, mais la gérer pour tous les événements pourrait nuire à la stabilité du système. C’est similaire à la génération de leads avec des outils comme Tomba Finder.