C'est assez efficace.
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.
En très gros,
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.
Les processus utilisateurs ont alors plus souvent la main, et plus longtemps
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.
la ou mon ravioli se met en ebulition, c'est si l'on doit etre root ET avoir un appli qui ai les options 'temps reel' comme XMMS (car si l'appli n'est pas prevu c'est rape), qu'elle interet pour le Desktop ?
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...
Ce patch est prévu pour réduire la latence des applications sensibles. Je ne crois pas que les environnements graphiques comme Gnome, Enlightenment ou KDE soient des applications nécessitant des priorités proches du temps réel. Le serveur X (qui est déjà lancé par root dans la plupart des cas) pourquoi pas, mais pas le window manager.
Les modifications à apporter son minimes (pour ne pas dire ridiculement simples). Pour passer en priorité max:
Et parmi les processus utilisateurs gourmants, il y a les interfaces graphiques.
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
un petit hdparm -u 1 /dev/le_bon_periph marche aussi pas mal
pour le cas que tu cites.
Lire le man avant car cela peut poser des problèmes corruptions parait-il.
<troll>
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)
Ce patch augmente les ressources disponibles pour les processus utilisateurs,
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.
J'utilise aussi le patch depuis plusieurs mois, sur ma machine qui me sert de desktop. Sur mon p2 400 comme sur mon athlon XP tout neuf, je peux pas dire que la différence de vitesse m'ai sauté aux yeux. J'avoue avoir du mal a me rendre compte. Par contre, la différence s'entend nettement quand on lace la lecture d'un mp3 avec mpg123 en pleine charge. Sans, le son a tendance a sauter, alors qu'avec la lecture est continue. Le probleme se pose moins avec xmms (grace a une gestion des buffers plus efficace?)
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 :)
Je confirme, ce n'est pas dû au patch.
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
La patch préemptif rend certains appels systèmes interruptibles
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 ?
Ces choses sont gérées par le noyau, en effet, lorsque l'on tourne sur un système SMP, ces problèmes d'appels systèmes interruptibles sont suceptibles d'arriver à tout moment (surtout au niveau des devices drivers).
Comme d'autres l'ont expliqué déjà, ce patch permet au noyau (aux appels systèmes en fait)
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).
Y'a un truc tres interessant dans ce patch est un meilleur support du signal MIDI pour controller des instruments de musique..En fait sans ce patch, l'utilisation du MIDI est TRES limitée..
Je croyais naivement que linux etait un multitache preemptif. Pour moi, le multitache cooperatif, c'est lorsque chaque programme decide lui-meme quand il renvoit la main (comme dans les MacOS < 10 ou tout le systeme pouvait se bloquer si on laissait le bouton de la souris enfonce), contrairement au preemptif ou c'est le systeme qui distribue le temps processeur.
Est-ce que quelqu'un aurait des details sur la difference preemptif/cooperatif ?
Bon, alors si j'ai bien compris:
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.
si j'ai bien compris, avec ce patch, un module mal écrit qui ne rendrait pas la main ne risquerait pas de bloquer la machine, juste consomer du CPU et on pourrait au moins faire un shutdown propre.
En général oui, mais j'ai eut un cas ou même les SysReq étaient inutilisables, lors de l'utilisation d'une carte TV supportée par le driver bttv, le fait d'afficher la vidéo à l'écran avait tendance à bloquer la machine au point que même alt-Sysrq-b ne fonctionnait plus (je n'avait jamais vu ça). Je soupsonne le driver NVidia d'en être la cause, je n'ai plus essayé avec la dernière version et j'hésite un peu.
Linux est multitache préemptif, mais au niveau user.
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.
En cela permet de ne pas avoir de notion de contexte d'execution en mode noyau. Si cela devient possible et que le noyau peut être interrompu, on gagne de la latence mais globalement on y perd car il y cette gestion supplémentaire.
Linux préférent, à prioris, faire la chasse aux latences plutot que d'activer ce genre d'option.
Linux est préemptif car le scheduling n'est pas mis en oeuvre seulement quand une tâche décide de s'arrêter.
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.
Au temps pour moi. je n'avais lu que les diffs présent sur le lien (kernel 2.4.7).
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 :)
Les process du système sont gérés de manière préemptive, c'est-à-dire que c'est le noyau qui ordonnance les tâches, pas de soucis de ce côté-là ; le "problème" étant pour le noyau lui-même : les différentes tâches du noyau travaillent en mode coopératif, chacune donnant la main quand elle a finit ce qu'elle a à faire.
Linux est préemptif, c'est à dire que le noyau coupe chaque tache à executer en segment de même durée (quantum), et le noyau commute entre chaque quantum à leur fin.
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.
Non, ce patch ne diminue le quantum de temps. Si je ne me trompes, le quantum c'est 2 ou 3 #define quelques parts, il n'y a pas besoin d'un patch aussi gros pour le changer...
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.
Effectivement, pour un desktop, ça a l'air vraimnt intéressant, mais le pb, c'est que le patch est pour les noyaux jusqu'au 2.4.7 seulement ! C'est un peu vieux quoi... Perso, actuellement je suis sur le kernel 2.4.16, ça fait une petite différence de version...
Ça fait un moment déjà que je suis sous 2.4.13 préemptible...
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... :)
Je ne sais pas si je suis le seul mais lorsque je choisis athlon dans la config des procs ... ca compile mais j'ai des unresolved symbol dans mes modules (A mon souvenir loop.o est dans le coup)
# 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.