• # Oui, mais

    Posté par . Évalué à 10.

    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.

    --
    Mieux vaut mourrir debout que vire à genoux
    • [^] # Re: Oui, mais

      Posté par (page perso) . Évalué à 10.

      Ca m'interresse, peux tu expliquer ce qui fait la difference entre les deux types de machines au niveau de ce patch ?

      Juste comme ca, pour ma culture personnelle ...
      • [^] # Re: Oui, mais

        Posté par . Évalué à 10.

        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.

        --
        Mieux vaut mourrir debout que vivre à genoux
        • [^] # Re: Oui, mais

          Posté par . Évalué à 10.

          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.
          • [^] # Re: Ui-met-bon

            Posté par (page perso) . Évalué à 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...
            • [^] # Re: Ui-met-bon

              Posté par . Évalué à 7.

              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:

              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 (page perso) . Évalué à 5.

          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

          • [^] # Re: Oui, mais

            Posté par (page perso) . Évalué à 1.

            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.
          • [^] # Re: Oui, mais

            Posté par (page perso) . Évalué à -1.

            <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)
        • [^] # Re: Oui, mais

          Posté par (page perso) . Évalué à 10.

          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.
          • [^] # Re: Oui, mais

            Posté par . Évalué à 10.

            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 :)
            • [^] # Re: Oui, mais

              Posté par . Évalué à 1.

              tu peux me mailer ton script? =) (sans le mp3, ca j'ai)

              Merci, ciao.
          • [^] # Freeze SpeedTouch USB

            Posté par (page perso) . Évalué à -1.

            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

          • [^] # Re: Oui, mais

            Posté par (page perso) . Évalué à 3.

            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 ?
            • [^] # Re: Oui, mais

              Posté par . Évalué à 3.

              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).
      • [^] # Re: Oui, mais

        Posté par (page perso) . Évalué à 7.

        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).
        • [^] # Re: Oui, mais

          Posté par . Évalué à 1.

          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..
        • [^] # Re: Oui, mais

          Posté par (page perso) . Évalué à 1.

          On se rapproche d'un noyau temps réel avec le patch preemp, alors ?

          Le patch est fait par qui ?
  • # linux n'est pas preemptif ?

    Posté par . Évalué à 5.

    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 ?
    • [^] # linux n'est pas preemptif ?

      Posté par . Évalué à 10.

      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.
      • [^] # Donc...

        Posté par . Évalué à 4.

        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.
        • [^] # Re: Donc...

          Posté par . Évalué à 1.

          Les Magic SysReq ça marche bien quand même :)
          • [^] # SysReq

            Posté par . Évalué à 3.

            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.
    • [^] # Re: linux n'est pas preemptif ?

      Posté par . Évalué à 10.

      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.
      • [^] # Re: linux n'est pas preemptif ?

        Posté par . Évalué à 7.

        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.

        nicO

        "La première sécurité est la liberté"

    • [^] # Re: linux n'est pas preemptif ?

      Posté par . Évalué à 6.

      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.
      • [^] # Re: linux n'est pas preemptif ?

        Posté par . Évalué à 4.

        Curieux. Très intrusif. x86-only.

        faux. dans le dernier changelog :

        Supported Arches: ARM, i386, and SH
        • [^] # Re: linux n'est pas preemptif ?

          Posté par . Évalué à -3.

          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 :)

          [-1, auto-flagellation]
    • [^] # Re: linux n'est pas preemptif ?

      Posté par (page perso) . Évalué à 10.

      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.
    • [^] # Re: linux n'est pas preemptif ?

      Posté par (page perso) . Évalué à 3.

      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.
      • [^] # Re: linux n'est pas preemptif ?

        Posté par (page perso) . Évalué à 5.

        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.
  • # c'est appetissant, mais...

    Posté par (page perso) . Évalué à 3.

    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...
  • # Processeur athlon

    Posté par . Évalué à 1.

    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)

    Une idée ??

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.