Si on résume la philosophie du patch, il réduit le temps de latence (jitter) de l'ordre de 200µs du temps de scheduling optimal.
Aller plus loin
- Le site du projet (10 clics)
Linux kernel preemption project
19
déc.
2001
Voici un petit patch qui permet de passer du mode coopératif en mode préemptif pour les noyaux Linux.
Si on résume la philosophie du patch, il réduit le temps de latence (jitter) de l'ordre de 200µs du temps de scheduling optimal.
Si on résume la philosophie du patch, il réduit le temps de latence (jitter) de l'ordre de 200µs du temps de scheduling optimal.
# Oui, mais
Posté par Badam Mitsui . Évalué à 10.
Toutefois, ce patch n'est à utiliser que pour des machines dites Desktop. Pour une machine type server l'utilisation de ce patch va au contraire faire baisser les performances.
Je sais que la plupart des administrateurs le savent, mais je le dis en avance par rapport à la question : "Mais pourquoi ce n'est pas par défaut dans les sources officielles du noyau ?"
Enfin, je crois que ce sera une option dans les sources pour 2.5.x et futurs noyaux.
--
Mieux vaut mourrir debout que vire à genoux
[^] # Re: Oui, mais
Posté par Jaimé Ragnagna (site web personnel) . Évalué à 10.
Juste comme ca, pour ma culture personnelle ...
[^] # Re: Oui, mais
Posté par Badam Mitsui . Évalué à 10.
Ce patch augmente les ressources disponibles pour les processus utilisateurs, et réduit le temps CPU disponible pour le système. Les processus utilisateurs ont alors plus souvent la main, et plus longtemps.
Ce n'est pas gênant, c'est même ce que l'on souhaite sur une machine Desktop, ou les ressources systèmes sont très peu utilisées.
Par contre pour une machine serveur, cela peut très fortement réduire les performances, notamment pour des serveurs comme Apache.
--
Mieux vaut mourrir debout que vivre à genoux
[^] # Re: Oui, mais
Posté par pas_moi . Évalué à 10.
Petite précision: c'est valable uniquement pour les processus qui en font la demande; et pour en faire la demande, il faut avoir les droits root. Très peu d'applications savent faire cette demande car très peu d'applications en ont besoin: par exemple, XMMS a cette option (afin de réduire la taille des buffers audio).
Je n'ai pas fait de tests de performances pour des applis classiques, mais je ne vois pas de raison de ne pas intégrer ce patch dans le noyau standard... enfin, au moins en 2.5.
[^] # Re: Ui-met-bon
Posté par Yohann (site web personnel) . Évalué à 5.
Je veux dire si l'on doit TOUT lancer en root, pour que Gnome, enlightenment se magne le train (quand seront prevu pour)... bonjour le retour en arriere...
[^] # Re: Ui-met-bon
Posté par pas_moi . Évalué à 7.
Les modifications à apporter son minimes (pour ne pas dire ridiculement simples). Pour passer en priorité max:
struct sched_param schp;
memset(&schp, 0, sizeof(schp));
schp.sched_priority = sched_get_priority_max(SCHED_FIFO);
sched_setscheduler(0, SCHED_FIFO, &schp);
et pour quitter:
struct sched_param schp;
memset(&schp, 0, sizeof(schp));
schp.sched_priority = sched_get_priority_max(SCHED_OTHER);
sched_setscheduler(0, SCHED_OTHER, &schp);
Les droits root sont nécessaires parce qu'autrement ça devient trop simple de planter la machine.
[^] # Re: Oui, mais
Posté par Robert Palmer (site web personnel) . Évalué à 5.
Concrètement ça permet à ton desktop/gestionnaire de fenêtres de garder un certaine fluidité même si ton système est sollicité à ce moment là.
Par exemple si tu fais un gros rippage de CD (donc beaucoup d'entrées/sorties) ton KDE ou ton Gnome seront aussi répondants que s'il ne se passait rien.
Je parle de KDE et Gnome car ils sont assez lourds et les effets du patch de préemptibilité sont plus visibles.
<troll>
C'est tout le contraire des Windows 9x qui se figeaient à la moindre utilisation du port // ou du lecteur de disquettes.
</troll>
Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment
[^] # Re: Oui, mais
Posté par Manu (site web personnel) . Évalué à 1.
pour le cas que tu cites.
Lire le man avant car cela peut poser des problèmes corruptions parait-il.
[^] # Re: Oui, mais
Posté par Benoît Déchamps (site web personnel) . Évalué à -1.
C'est tout le contraire des Windows 9x qui se figeaient à la moindre utilisation du port // ou du lecteur de disquettes.
</troll>
Rien n'a changer, il suffit de copier un CD-ROM sur le disque dur ou un gros fichier à partir du réseau et ca suffit a rendre un win2000 quasiment inutilisable ...
(-1)
[^] # Re: Oui, mais
Posté par Gaël Le Mignot . Évalué à 10.
Pas vraiment. Ce patch n'augmente aucune ressource. Il permet juste de réaliser de la commutation de contexte (changer le processus ayant accès au processeur) en mode noyau.
Comme cela a été dit sur les autres commentaies, lorsqu'un processus passe en mode noyau (par un appel système), il n'est plus interruptible; il faut attendre que le traitement de l'appel système soit terminé pour que le processeur puisse être donné à une autre tache.
La patch préémptif rend certains appels systèmes interruptibles, ce qui augmente la réactivité du système (mais pas la vitesse). En particulier, il permet à X ou aux window managers d'avoir accès au CPU à intervalles plus réguliers même lorsque le système est très chargé (et swap beaucoup), et augmente ainsi l'impression de vitesse pour l'utilisateur.
Perso j'utilises ce patch depuis plusieurs mois, et si je n'ai pas vu de différences fondamentales (sur mon Athlon avec 512M de RAM la machine est rarement chargée), il y a quand même une amélioration quand je fais des 'make -j3 bzImage' ou des 'diff -R' sur les sources du noyau. Par contre j'ai eu un freeze une fois en faisant de l'hotplug avec mon Speedtouch USB, mais je ne sais pas si c'est du au patch préemptif ou pas.
[^] # Re: Oui, mais
Posté par f l . Évalué à 10.
Par ex, sur ma machine, j'ai un script dans /etc/init.d qui lance la lecture d'un mp3 avec mpg123 au démarrage (TATATAAA TATATATAAAAA -générique de star trek- Welcome to the final frontier!..moi ca me fait bien rigoler^_^).
Sauf que quand je me logue et que je fais startx, la lecture du mp3 part completement en couille pendant quelques secondes, meme avec l'athlon xp.
Alors qu'avec le patch préemptif, il y a parfois un petit scratch mais c'est tout :)
En conclusion, ce patch n'est pas terriblement utile ni indispensable, mais si vous avez une machine desktop vous ne risquez rien a l'essayer :)
[^] # Re: Oui, mais
Posté par woof . Évalué à 1.
Merci, ciao.
[^] # Freeze SpeedTouch USB
Posté par Infernal Quack (site web personnel) . Évalué à -1.
J'ai aussi freezé mon ordi en hotpluguant mon speedtouch USB :(
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Oui, mais
Posté par Sylvain Rampacek (site web personnel) . Évalué à 3.
A mon avis, ceci peut être très dangereux...
Mais vu qu'il faut préciser dans le code de l'appli que l'on veut cela, le problème ne se pose pas pour un programmeur système averti...
Mais les appels systèmes qui deviennent interruptibles, comment sont-ils repris ? Ils reprennent où ils en étaient exactement, recommencent ou abandonnent ?
Ensuite, si une lecture/écriture dans un processus A est bloqué par une écriture dans un processus B, et que le processus B est interrompu, comment cela est géré, le processus A attend toujours ou A prend la main... ?
Enfin, si le "patch est activé" dans un programme lançant un exec sur un binaire qui lui ne gère pas ce patch, l'activation est-elle gardée ?
[^] # Re: Oui, mais
Posté par kadreg . Évalué à 3.
[^] # Re: Oui, mais
Posté par Francois Revol (site web personnel) . Évalué à 7.
d'être préemptés, presque comme si'ils s'exécutaient en mode user.
Le problème c'est que pour arriver à faire ça sans tout faire planter il faut mettre des sémaphores et autre joyeusetés un peu partout dans le code du noyau, pour garantir l'exclusion mutuelle de certaines sections critiques qui avant étaient forcément atomiques, puisque c'est le code qui décidait de rendre la main seulement à la sortie de telles sections (en général avec interruptible_wait_on() quand on attend une ressource).
Le problème c'est que la gestion de tous ces sémaphores complique le code, mais surtout augmente le temps passé au total.
Ainsi, un noyau patché sera plus rapide à répondre, ce qu'on veut pour du desktop, (à la BeOS), mais les performances globales seront légèrement inférieures (= temps d'exécution total) qu'avec un noyau non patché.
Pour la plupart des serveurs on va préférer la performance brute sans se soucier du temps de latence, donc on oublie le patch.
(de toutes façon la latence des réseaux est bien plus grande que la latence dans le noyau, donc le gain serait négligeable dans le cas d'un serveur réseau et les perfs seraient moindres pour rien).
[^] # Re: Oui, mais
Posté par sToR_K . Évalué à 1.
[^] # Re: Oui, mais
Posté par Pooly (site web personnel) . Évalué à 1.
Le patch est fait par qui ?
# linux n'est pas preemptif ?
Posté par Étienne . Évalué à 5.
Est-ce que quelqu'un aurait des details sur la difference preemptif/cooperatif ?
[^] # linux n'est pas preemptif ?
Posté par kalahann . Évalué à 10.
Quand on dit que linux est préempTIF, ça veut dire en fait qu'il prend la main aux applications une fois le temps processeur expiré. Mais jusqu'à présent seuls les processus étaient préempTIBLES, pas le kernel. S'il devait faire une opération longue, rien ne pouvait le stopper. Maintenant, avec ce patch c'est possible et tu n'as plus à attendre après le kernel aussi longtemps qu'avant. Ca va augmenter ausi le nombre de changements de contexte, d'où la baisse de perfs sur les serveurs.
[^] # Donc...
Posté par wismerhill . Évalué à 4.
[^] # Re: Donc...
Posté par kadreg . Évalué à 1.
[^] # SysReq
Posté par wismerhill . Évalué à 3.
[^] # Re: linux n'est pas preemptif ?
Posté par kadreg . Évalué à 10.
Au niveau noyau, en revanche, il est plutot coopératif (par processeur, le cas SMP est plus tordu). La notion de tache n'y existe pas. Ce qui se passe dans le noyau est totalement différent de ce qui se passe en userspace.
[^] # Re: linux n'est pas preemptif ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Linux préférent, à prioris, faire la chasse aux latences plutot que d'activer ce genre d'option.
nicO
"La première sécurité est la liberté"
[^] # Re: linux n'est pas preemptif ?
Posté par Jean-Yves B. . Évalué à 6.
L'exemple simple est de faire un programme avec une boucle infinie vide dedans (une sorte de spin-lock sans fin) et de remarquer que, même si cette tâche se met à bouffer le CPU à mort, le reste marche toujours.
Le patch rajoute à priori la possibilité de faire préemption à un autre niveau, en violant plus ou moins les règles d'ordonnancement d'origine.
Curieux. Très intrusif. x86-only.
Intérêt majeur : montrer au monde qu'un serveur et une machine « desktop » ont un comportement attendu différent.
[^] # Re: linux n'est pas preemptif ?
Posté par daniel . Évalué à 4.
faux. dans le dernier changelog :
Supported Arches: ARM, i386, and SH
[^] # Re: linux n'est pas preemptif ?
Posté par Jean-Yves B. . Évalué à -3.
Pour avoir les dernières versions il faut suivre le lien "Robert Love's latest bidule ...".
Encore une fois, ma flemme me fait dire des conneries :)
[-1, auto-flagellation]
[^] # Re: linux n'est pas preemptif ?
Posté par Annah C. Hue (site web personnel) . Évalué à 10.
[^] # Re: linux n'est pas preemptif ?
Posté par Mouns (site web personnel) . Évalué à 3.
Dans le multitache coopératif, c'est au processus de provoquer la commutation.
Le role du patch en question, est reduire le quantum, car sur un 386 DX 20 MHz le quatum était suffisament court en cycle. Mais maintenant, sur les processeur à 1 GHz, on peut le réduire facilement sans perte de performance, car il y a beaucoup plus de cycles.
[^] # Re: linux n'est pas preemptif ?
Posté par Gaël Le Mignot . Évalué à 5.
Comme je l'ai dit plus haut, ce patch diminue le nombre d'appeles systèmes non interruptibles, c'est à dire qu'il diminue les cas où le quantum est épuisé mais le processus courant garde la main parce qu'il effectuait une opération bloquant en mode noyau.
# c'est appetissant, mais...
Posté par Julien Portalier . Évalué à 3.
[^] # Re: c'est appetissant, mais...
Posté par bmc . Évalué à 5.
Va jeter un oeil sur http://www.tech9.net/rml/linux/(...) , tu auras même le patch pour le 2.4.17-rc1 (manque encore celui pour le rc2 à l'heure où j'écris, ne leur en veut pas trop... :)
[^] # Re: c'est appetissant, mais...
Posté par Gaël Le Mignot . Évalué à 4.
On s'en fout => -1
# Processeur athlon
Posté par Fred Henri . Évalué à 1.
Une idée ??
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.