Timers haute résolution et horloge dynamique.

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
30
juin
2006
Linux
Thomas Gleixner et Ingo Molnar ont produit un patch pour le noyau Linux 2.6.17 qui apporte deux améliorations concernant l'horloge et les interruptions associés sur architecture x86 (y compris SMP) et prochainement sur x86_64, PPC et ARM.

La première amélioration concerne la précision de l'horloge, cette modification permet aux timers POSIX et à la fonction nanosleep() d'atteindre la précision offerte par le matériel, typiquement 1µs sur un PC classique, et ceci de manière totalement transparente. L'implémentation classique du noyau s'appuie sur la valeur de HZ, ce qui offre une précision médiocre de 1ms à 10 ms (1ms pour les noyaux compilés avec HZ=1000Hz)

La seconde amélioration appelée "tickless kernel" pourrait être traduite par "Noyau sans tic d'horloge" ou "sans métronome". Il est possible de choisir à la compilation un mode dans lequel il n'y a plus de signal d'horloge périodique, l'horloge est alors programmée à chaque fois en fonction de la prochaine interruption d'horloge nécessaire. S'il n'y a aucun besoin pendant 1,5 secondes, le processeur restera réellement en état IDLE pendant 1,5 secondes. D'après les développeurs, les interruptions d'horloge sont réduites à 1 ou 2 par seconde. L'implémentation actuelle du noyau fait qu'une interruption d'horloge arrive avec la périodicité définie à la compilation (100Hz, 250Hz ou 1000Hz) même lorsque cela n'est pas nécessaire.

Cette amélioration permet de réduire la consommation du processeur et de ce fait, réduire la chaleur dégagée et augmenter l'autonomie de la batterie dans le cas d'ordinateurs portables. En prime c'est une solution à un problème récent: certains utilisateurs des Core-Duo d'Intel, en particulier sur les MacBook d'Apple, se plaignent d'entendre les interruptions de l'horloge lorsque leur processeur est au repos (probablement à cause des pics de courant générés avec une fréquence audible et d'un couplage inductif), l'absence de ces interruptions devrait leur permettre de retrouver le silence.

Aller plus loin

  • # bravo pour la qualité de la dépêche

    Posté par  . Évalué à 10.

    Ben oui.. je ne sais pas si ça se fait, mais voilà une belle dépêche concise mais précise, alors bravo au contributeur.

  • # supaire...

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

    c'est une très bonne idée... mais pas si nouvelle que ça :)

    • [^] # Re: supaire...

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

      un argumentaire ? des liens ? cela avait été implémenté auparavant ?

      • [^] # Re: supaire...

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

        N'en déplaise à ceux qui m'on mis -2, et pour avoir vu le code en question, BeOS a toujours fait ça.
        D'ailleurs c'est ce qui faisait qu'il ne bootait pas sur mon portable, à cause du chipset ATI IXP buggué qui ne supportait pas le mode du PIT qu'il utilisait, tous les autres OS utilisant le mode 0 (de mémoire) qui est l'interruption périodique.
        BeOS reprogrammait le PIT à chaque fois suivant les besoins.
        Et Haiku fait la même chose, il suffit d'aller voir dans le SVN !

  • # phénomène récent, ... ou pas

    Posté par  . Évalué à 5.

    En prime c'est une solution à un problème récent: certains utilisateurs des Core-Duo d'Intel, en particulier sur les MacBook d'Apple, se plaignent d'entendre les interruptions de l'horloge lorsque leur processeur est au repos (probablement à cause des pics de courant générés avec une fréquence audible et d'un couplage inductif), l'absence de ces interruptions devrait leur permettre de retrouver le silence.

    C'est pas un phénomène récent. J'ai un laptop qui à 3 ans avec un AMD qui doit tourner autour de 1.4GHz si mes souvenirs sont bon, et qui produit le même sifflement, vraissemblablement pour les mêmes raisons. Perso ça ne me gène pas mais je conçois que ça peut déranger certains.

    • [^] # Re: phénomène récent, ... ou pas

      Posté par  . Évalué à 4.

      Donc en résumé il suffirait de recompiler son noyau en modifiant la valeur de HZ pour atténuer le problème ? (à 100 ça doit être moins audible qu'à 1000 j'imagine)

      Corollaire : y'a moyen de faire de la musique avec un module noyau ad'hoc ? (OK je sors... :)

      • [^] # Re: phénomène récent, ... ou pas

        Posté par  . Évalué à 6.

        J'avais fait un programme faisait de la musique grâce au processeur de ma HP49, sans l'aide du buzzer intégré à la calculatrice. Mais comme on ne pouvait pas descendre dans la plage des fréquences audibles, il a fallu faire de la modulation de signal. Du coup, il fallait un poste de radio AM pour écouter le signal électromagnétique émis par le processeur (un Saturn à 4 MHz).

        Mais même sans mon petit programme de démo, on peut déjà entendre sur le poste radio le cliquetis à 16 Hz des interruptions du système, et le son aigü des interruptions beaucoup plus rapprochées lorsque la touche ON est appuyée.

    • [^] # Re: phénomène récent, ... ou pas

      Posté par  . Évalué à 1.

      Dans le même genre, j'ai un collègue qui a une clef USB qui siffle.
      Cela a un avantage malgrès que le bruit soit désagréable: on ne risque pas d'oublier la clef USB branchée dans un PC!

  • # Nouveau?? Comment çà marche?

    Posté par  . Évalué à 3.

    La seconde amélioration appelée "tickless kernel" pourrait être traduite par "Noyau sans tic d'horloge" ou "sans métronome".
    C'est nouveau ce truc là?
    C'est la première implémentation ou certains SE le font déjà?

    S'il n'y a aucun besoin pendant 1,5 secondes, le processeur restera réellement en état IDLE pendant 1,5 secondes.
    Et comment on sait quand il n'y a aucun besoin?
    On baisse la fréquence en fonction de la charge processeur, c'est çà?

    Interessant en tout cas cette (très bien rédigée) info.

    • [^] # Re: Nouveau?? Comment çà marche?

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

      Je ne connais pas cette implémentation mais c'est pas en fonction de la charge processeur qu'il faut compter
      mais en fonction du nombre de processus qui ont besoin du CPU
      si un seul a besoin du CPU ca sert à rien de relancer l'ordonanceur si c'est pour réélire le meme process

    • [^] # Re: Nouveau?? Comment çà marche?

      Posté par  . Évalué à 4.

      Je ne sais pas si d'autre SE pour ordinateur de bureau, serveur utilise ceci. Certains systèmes embarqués l'utilisent.

      En regardant l'ordancement des tâches, la plus par des tâches ne demandant pas beaucoup de calcul sont toutes en attente d'un évenement. Cet évenement fait toujours suite à une interruption (donnée sur carte réseau, disque, timer) même si le processus demandait une donnée d'un autre processus. Ainsi, si aucun processus ne demande pas du temps cpu sans condition (typiquement le cas de gros calcul), le système peut se mettre en attente d'une interruption materiel. Les 1.5secondes sont alors le temps entre la dernière utilisation du cpu et la première interruption matériel. Ce temps ne peut-être prédit par définition.

      Le timer n'est par la suite utilisé uniquement dans le cas d'un sleep ou après l'allocation de temps cpu à une application afin que celle-ci n'utilise pas le cpu indéfiniment si d'autre applications demande aussi du temps cpu.

      Sinon, la fréquence du cpu n'intervient pas ici même si on pourrais coupler ces deux fonctionnalités.

      En espérant être clair et non alice.

    • [^] # Re: Nouveau?? Comment çà marche?

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

      > C'est la première implémentation ou certains SE le font déjà?

      BeOS, Haiku...

    • [^] # Re: Nouveau?? Comment çà marche?

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

      Pour faire simple, avant, quand tu avais un rendez-vous, tu regardait ta montre toutes les 5 minutes.
      Maintenant, tu utilise ton portable/PDA qui te bippe au bon moment.
      = moins de temps gaspillé.

      • [^] # Re: Nouveau?? Comment çà marche?

        Posté par  . Évalué à 2.

        Donc si je comprends bien ça veut dire que là où avant le noyau programmait une fois pour toutes le timer pour fixer des rendez-vous périodiques, maintenant ce dernier est constamment reprogrammé pour chaque rendez-vous suivant ?

        OK, mais je me demande un truc : est-ce que la reprogrammation du timer est coûteuse en nombre de cycles CPU ? Si oui, ça veut dire qu'on risque de perdre un peu en performances non ?

        • [^] # Re: Nouveau?? Comment çà marche?

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

          C'est possible qu'en performance brute avec beaucoup d'évènement à gérer on perde quelques cycles... mais la souplesse gagnée compense largement.

        • [^] # Re: Nouveau?? Comment çà marche?

          Posté par  . Évalué à 4.

          est-ce que la reprogrammation du timer est coûteuse en nombre de cycles CPU ? Si oui, ça veut dire qu'on risque de perdre un peu en performances non ?

          Ca consiste juste à écrire une valeur (le nombre de coups d'horloge à compter jusqu'à la prochaine interruption) dans un registre du timer. C'est un seul accès sur le bus, a mon avis c'est négligeable.

          Sur le principe, je pense que dans les cas où on a beaucoup d'entrées-sorties (donc des attentes d'interruption) et/ou plein de process qui se synchronisent (sémaphores et mutexes), ce système est positif car il évite d'appeler le séquenceur pour rien (de toute façon il est appelé assez souvent).

  • # patch sur le patch

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

    Si vous êtes un utilisateur du kernel 2.6.17.1 vous aurez peut-être besoin de la petite correction disponible a l'adresse suivante :
    http://lkml.org/lkml/2006/6/25/58

    En effet, sans cette petite correction vous aller essuyer un ennuieux :
    WARNING: /lib/modules/2.6.17.1-1xxx/kernel/drivers/acpi/processor.ko needs unknown symbol hrtimer_restart_sched_tick
    WARNING: /lib/modules/2.6.17.1-1xxx/kernel/drivers/acpi/processor.ko needs unknown symbol hrtimer_stop_sched_tick

    Vala bonne chance ;)

Suivre le flux des commentaires

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