Journal Noyau: code relatif à l'HyperThreading défectueux?

Posté par  .
Étiquettes :
0
30
août
2006
Salut journal.
Je t'écris parce que j'ai de plus en plus de doutes sur la qualité du code pour le support de l'HyperThreading de mon OS.
Je m'explique: il y a quelques temps, j'utilisais Amarok qui plantait environ 10 fois par jour, à n'importe quelle occasion.
J'étais passé à xmms, puis avais trouvé, quelques mois plus après, ceci:
http://bugs.kde.org/show_bug.cgi?id=99199

Donc je n'étais pas le seul. Ce qui m'a étonné, c'est qu'apparemment amarok fonctionnait bien sur des multi-processeurs, et que le seul moyen de le rendre stable sur un HT, c'était d'utiliser "l'hard affinity", en gros de le faire tourner sur un seul processeur si la machine hôte est un HT. Depuis, il n'a plus planté une seule fois, pourtant il tourne toute la journée.

Là encore, je m'apperçois que j'ai des problèmes avec kaffeine: je reboote sur un noyau sans HT, et là, plus de problèmes.

Donc là encore, le problème vient de mon P4HT.

J'aurais été tenté de croire que les responsables étaient les auteurs de amarok/kaffeine, qui auraient laissé traîner quelques sections critiques non protégées, et donc non multithread-safe. Mais apparemment, ces programmes tournent bien sur des vrais multi-processeurs.
Donc le problème viendrait de plus bas, et donc probablement du noyau.

Alors mon journal, est-ce que je suis le seul à avoir des soucis avec l'HT, est-ce que mes conclusions tiennent la route?

  • # Strictement aucun probleme pour moi.

    Posté par  (site web personnel) . Évalué à 2.

    Possesseur depuis un bon bout de temps un P4 'B' à 3.06Ghz (le tout premier des P4 à supporter l'HT), je n'ai jamais eu de plantages d'amarok (enfin peut etre mais je m'en souviens plus donc on peut pas vraiment considerer ca comme instable en tout cas).

    D'ailleur tout continue à très bien marcher, meme si je fais un make -j2 sur un gros projet...

  • # humm

    Posté par  . Évalué à -2.

    Salut,

    Il y a tous les outils disponibles pour savoir de quoi ca vient !
    analyse le core et tu auras la reponse !

    Tu aurais pu au moins preciser:
    la distrib ?
    quelle version du noyau ?
    la temperature de ton CPU ?
    si memetest passe ?

    (perso, je chercherai plus du coté pilote audio :
    maj kernel et alsa.
    maj BIOS de la carte mere)

    a+

    • [^] # Re: humm

      Posté par  . Évalué à 2.

      Il n'y a pas de core, et le backtrace est inexploitable (ouais, faudrait que je le compile avec les infos de debug), mais ça ne changerait rien au problème.
      Comme je l'ai dit, et comme le montre le lien que j'ai montré, l'HT cause des problèmes.
      Je me cite:
      "Là encore, je m'apperçois que j'ai des problèmes avec kaffeine: je reboote sur un noyau sans HT, et là, plus de problèmes."

      En plus, je ne suis pas le seul, comme en témoigne le thread:
      http://bugs.kde.org/show_bug.cgi?id=99199

      Ce qu'il y a, c'est qu'une appli comme amarok fait un usage intensif de threads, ce qui pourrait expliquer pourquoi il plantait fréquemment.

      D'ailleurs, sur un changelog d'amarok:

      * Workaround for stability issues with HyperThreading on Linux.
      Added a configure check to deal with buggy GLIBC's. (BR 99199)

  • # Uniquement HT et pas SMP

    Posté par  . Évalué à 2.

    J'avais le même problème sous une Gentoo, mais au lancement Amarok me prevenait du problème et indiquait quil fallait désactiver le support du HT dans le kernel (paramètre noht a passer au noyau si mes souvenirs sont exactes).

    Ceci dit, tu peux profiter quand même de l'hyperthreading en gardant le support SMP (Gestion de plusieurs CPU). Le code restant instable amarok etant vraiment spécifique qu'a l'hyperthreading.

    En plus je crois que ce qu'apportes ce code est minime, en tout cas j'ai jamais fais de difference entre un noyau avec l'option hyperthreading et sans ...

    • [^] # Re: Uniquement HT et pas SMP

      Posté par  . Évalué à 2.

      Intéressant ça...

      Moi je n'ai jamais compris l'engouement pour Amarok car à chaque fois que je le test il plante très très rapidement (quelque soit le backend).
      J'ai un P4 HT donc c'est peut-être la raison. A l'occasion de je réessayerai en désactivant le HT.

      • [^] # Re: Uniquement HT et pas SMP

        Posté par  . Évalué à 2.

        Hormis ce problème la, j'ai jamais eu de soucis de stabilité avec (j'utilise xine en backend), ça depend peut etre de la distrib ... ou d'autres parametres t'echappant :)

        • [^] # Re: Uniquement HT et pas SMP

          Posté par  . Évalué à 3.

          Le problème m'a paru indépendant de la distrib pour en avoir testé pas mal.
          Ceci dit j'ai exactement le même problème avec kontact... Et comme personne ne se plaint à outrance de la stabilité de kontact et Amarok et que chez moi ça a toujours été inutilisable (un plantage ~ 5mn) j'ai toujours suspecté un problème inhérent à ma config.

      • [^] # Re: Uniquement HT et pas SMP

        Posté par  (site web personnel) . Évalué à 2.

        T'inquietes, chez moi, c'est très plantogène aussi sur un AMD sans HT alors ...

        Enfin, ces jours-ci, je lui ai redonné une chance, il plante presque plus, alors qu'à une époque, c'était 5minutes d'uptime moyen.

        • [^] # Re: Uniquement HT et pas SMP

          Posté par  . Évalué à 2.

          Tiens, pareil sur mon AMD sous Gentoo. En fait, le plantage c'était que la musique s'arrêtait toute seule au bout d'un moment (quel que soit le backed), mais la GUI ne freezait pas avant que j'appuie sur un bouton (comme "play" ou "stop", par exemple).

          Aujourd'hui, sur mon Core Duo sous Ubuntu, aucun problème.

          Cela dit, je n'ai jamais réussi à isoler d'où ça venait, et je n'ai jamais vu une seule allusion à ce problème dans les forums.

    • [^] # Re: Uniquement HT et pas SMP

      Posté par  . Évalué à 1.

      C'est un problème de synchronisation. Après, savoir si ça vient d'Amarok, xine, ou du kernel, je ne sais pas.

      Je tiens à préciser qu'avant que le patch "hard affinity" ne soit appliqué, Amarok plantait 10 fois par jour, maintenant il ne plante jamais.

      En fait, je voudrais savoir si ça vient de l'ordonnanceur HT du noyau, ou bien du code lui-même.
      Donc, si quelqu'un avait un multi-processeur, est-ce qu'il pourrait de switcher plusieurs fois de canaux audios lorsqu'il lit un dvd dans kaffeine?

      Sinon, la discussion se focalise sur Amarok, mais étant donné que les dernières versions sont patchées, on ne peut plus en apprendre grand chose.

      • [^] # Re: Uniquement HT et pas SMP

        Posté par  . Évalué à 3.

        Sur les multiprocesseurs ça marche trés bien comme je l'expliquais dans mon 1er message, c'est uniquement avec le support HT que ça plantes. Tu gardes juste le support SMP, amarok plantes plus et en plus tu continu de profiter de l'HT ...

        Et je sais toujours pas ce qu'apportes cette option du noyau par rapport au SMP :D

        • [^] # Re: Uniquement HT et pas SMP

          Posté par  . Évalué à 2.

          Effectivement, il semblerait que c'est le HT (option "SMT scheduler") qui pose problème. Par rapport au SMP, ç'est censé apporter une meilleure répartition des threads, mais visiblement le jeu n'en vaut pas la chandelle. D'ailleurs, je crois que Windows aussi a des problèmes, j'ai déjà eu des freezes en lançant 2 applications en même temps.
          Bref, j'ai l'impression que l'HT n'est pas l'invention de siècle - des experts en architecture pour confirmer/infirmer?

          P.S: on doit pouvoir le désactiver en passant l'option "noht" au boot.

          • [^] # Re: Uniquement HT et pas SMP

            Posté par  (site web personnel) . Évalué à 2.

            Le SMT permet d'avoir 2 processeurs qui partagent leurs unité de calculs (en fait seul les registres et l'étage de fetch est dupliqué). Cela permet une meilleur utilisation des ressources (moins de temps à ne rien faire) et cela permet une latence beaucoup plus faible pour la réaction à un événement (moins de changement de contexte)

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

          • [^] # Re: Uniquement HT et pas SMP

            Posté par  . Évalué à 4.

            D'ailleurs, je crois que Windows aussi a des problèmes, j'ai déjà eu des freezes en lançant 2 applications en même temps.

            Je confirme. Sous windows certains programmes se comportent bizarrement avec l'HT. Le débuggage d'un programme dans Visual Studio 2005 part très facilement en sucette avec l'HT activé. Bilan, beaucoup de développeurs désactivent l'HT pour ne pas être emmerdés.

            Bref, j'ai l'impression que l'HT n'est pas l'invention de siècle

            C'était surtout un gros hack pour compenser le pipeline démesurément long du P4. Ca n'a aucun intéret sur un AMD et ça n'en n'a plus vraiment non plus sur la nouvelle architecture Intel (qui pourtant a quand même le flag HT, sans doute pour forcer les compilateurs activer certaines optimisations faciles à paralléliser sur un multi coeur). Au final, avec la démocratisation du vrai multi coeur, l'HT devrait vite se faire oublier.

  • # Autre noyau ?

    Posté par  . Évalué à 5.

    Tu as essayé avec un BSD par exemple ? Ca serait intéressant.

  • # Real time event ?

    Posté par  . Évalué à 2.

    sur le lien il y avait marqué :
    "Program received signal SIG43, Real-time event 43. "
    Si ca se trouve il s'agit simplement que le HT te fait perdre trop de temps.
    Le HT c'est de la **** pour tout ce qui est calcul threadé (problème avec l'accés au bus mémoire toussa).
    Si amaraok lance deux threads , l'un qui tourne en essayant de changer une variable, et un autre qui essaie de lire une autre variable mais que le bus est pris par le premier threads , tu vas rallonger tes délais toussa.
    Et si le délai devient trop grand pour ne plus assurer le temps réel , le noyau ne risque t'il d'envoyer un signal real time event ? (je sais pas quand ce signal est généré).
    Bref moi je pense plutot pour un probleme qui vient du HT et non pas du code.
    Si le code passe sans aucun probleme sur un quadriproc , il n'y a aucune raison qu'il ne passe pas sur une p4HT

    • [^] # Re: Real time event ?

      Posté par  . Évalué à 1.

      Pour info man 7 signal:

      Real-time Signals
      Linux supports real-time signals as originally defined in the POSIX.4 real-time extensions (and now included in POSIX 1003.1-2001). Linux supports
      32 real-time signals, numbered from 32 (SIGRTMIN) to 63 (SIGRTMAX). (Programs should always refer to real-time signals using notation SIGRTMIN+n,
      since the range of real-time signal numbers varies across Unices.)

      Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined
      purposes. (Note, however, that the LinuxThreads implementation uses the first three real-time signals.)

      The default action for an unhandled real-time signal is to terminate the receiving process.

      Real-time signals are distinguished by the following:

      1. Multiple instances of real-time signals can be queued. By contrast, if multiple instances of a standard signal are delivered while that signal
      is currently blocked, then only one instance is queued.

      2. If the signal is sent using sigqueue(2), an accompanying value (either an integer or a pointer) can be sent with the signal. If the receiving
      process establishes a handler for this signal using the SA_SIGINFO flag to sigaction(2) then it can obtain this data via the si_value field of
      the siginfo_t structure passed as the second argument to the handler. Furthermore, the si_pid and si_uid fields of this structure can be used
      to obtain the PID and real user ID of the process sending the signal.

      3. Real-time signals are delivered in a guaranteed order. Multiple real-time signals of the same type are delivered in the order they were sent.
      If different real-time signals are sent to a process, they are delivered starting with the lowest-numbered signal. (I.e., low-numbered signals
      have highest priority.)

      If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first. Linux, like many other
      implementations, gives priority to standard signals in this case.

      According to POSIX, an implementation should permit at least _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process. However, Linux
      does things differently. In kernels up to and including 2.6.7, Linux imposes a system-wide limit on the number of queued real-time signals for all
      processes. This limit can be viewed and (with privilege) changed via the /proc/sys/kernel/rtsig-max file. A related file, /proc/sys/kernel/rtsig-
      nr, can be used to find out how many real-time signals are currently queued. In Linux 2.6.8, these /proc interfaces were replaced by the
      RLIMIT_SIGPENDING resource limit, which specifies a per-user limit for queued signals; see setrlimit(2) for further details.

Suivre le flux des commentaires

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