Modification du timer du noyau 2.4

Posté par  (site web personnel) . Modéré par Fabien Penso.
Étiquettes :
0
21
oct.
2002
Linux
Robert Love a récemment backporté un patch intégré au noyau de développement 2.5. Celui-ci permet de modifier la fréquence du timer du noyau. Réglé à 100 (Hz) dans le noyau 2.4, il a été augmenté à 1000 dans le noyau 2.5. L'article sur KernelTrap nous apprend le pourquoi du comment et surtout les implications de ce changement.

Aller plus loin

  • # Re: Modification du timer du noyau 2.4

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

    Modifier le timer va introduire un overhead de traitement mais negligeable selon l'article.

    Il y a quelques temps un article évoquait un mode "batch" de linux qui passait le timeslice à 1,5 secondes pour des traitements long.

    Si quelqu'un pouvait m'expliquer le lien entre timeslice et timer...

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

    • [^] # Re: Modification du timer du noyau 2.4

      Posté par  . Évalué à 1.

      il n'y a pas forcement de lien.

      Le timeslice c'est l'intervalle de temps alloué par le scheduleur a une tache.
      Le scheduleur se pose la question a intervalle reguliers (different ou pas du timeslice), a chaque fois qu'une interuption le reveille.

      Le HZ, c'est la frequence programmée des interruptions liées a l'horloge. Suite a cette interruption, les OS font toutes les taches répétitives:
      - incrementer le compteur de temps (uptime)
      - lancer le scheduleur
      - ...

      Dans le code de l'interuption d'horloge, on peut decider faire certaines actions une fois sur 2 par exemple. En fait toutes les reactions "programmées" interviendront lors d'une de ces interruptions, donc apres un multiple de 1/HZ seconde.

    • [^] # Re: Modification du timer du noyau 2.4

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

      Oui, je me demande effectivement s'il n'y aura pas un overhead significatif en faisant cela.

      Probablement, ce qui serait intéressant, puisque le gros bénéfice d'avoir un HZ élevé est une plus faible latence, serait d'avoir un HZ qui s'auto-adapte en se diminuant lorsque le load s'accroît. De cette manière, il y aura du bénéf pour tous.

  • # Re: Modification du timer du noyau 2.4

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

    Je comprends pas réellement la nature de la modification dans le kernel, mais sur une de mes applis ça interfere grandement:

    On a une routine qui fait un read avec timeout. Sur le kernel de la redhat 8.0, et le 2.5 la routine sort 10 fois plus rapidement en timeout ... Pour ainsi dire nous avons été obligé d'augmenter le timeout dans toutes les parties du programme pour que ça soit compatible avec le 2.5 voir 2.6, et le kernel Redhat 8.0

    code34

    • [^] # Re: Modification du timer du noyau 2.4

      Posté par  . Évalué à 1.

      Et bien justement, cela c'etait avant le patch de Robert Love, si je comprends bien, il a modifi'e le kernel de maniere a ce que le code utilisateur ne soit pas impacte par le passage du HZ a 1000.

      • [^] # Re: Modification du timer du noyau 2.4

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

        Heu ... je crois plutot que c'est le contraire. Le patch est proposé pour les 2.4 et déjà actifs sur les 2.5, donc les problemes que j'ai trouvé sur les 2.5 pourraient se reproduire aussi sur les 2.4 ;)

        code34

    • [^] # Re: Modification du timer du noyau 2.4

      Posté par  . Évalué à 1.

      > la routine sort 10 fois plus rapidement en timeout ...

      Bizarre ton truc. la fonction read() ne peut retourner sur timeout (du moins pour un fichier sur disque). De plus on ne peut spécifier de timeout avec read().
      La fonction select() ne retourne pas de timeout non plus et le timeout que tu peux exprimer dans select() est en seconde (struct timeval ou équivalent) et pas en cycle du noyau. De plus, la librairie C n'utilise pas les cycles noyaux (sinon le patch proposé fournirai aussi un patch pour la libc :-) ).

      Par contre, si tu fait un truc du style :
      while (1) {
      select(.... *timeout = 0) ;
      }
      ben tu sors dix fois plus souvent de select() sans rien à lire ou écrire avec un 2.5. Et c'est normal (voir l'article :-) ). Mais utiliser un tel algorithme n'est pas très judicieux (le cpu tourne a fond pour rien) !
      Si c'est vraiment nécessaire, le mieu est de faire un fork() avec un processus qui block sur select(... timeout = NULL) et pour communiquer entre processus d'utilise ipcs et/ou les signaux (ou d'utiliser le multi-threading (mais j'y connais) ).

      • [^] # Re: Modification du timer du noyau 2.4

        Posté par  . Évalué à 1.

        > (mais j'y connais)

        Lire :
        (mais je n'y connais rien)

        Désolé.

        • [^] # Re: Modification du timer du noyau 2.4

          Posté par  . Évalué à 1.

          Non ca bouffe pas du temps CPU paske le processus perd la main sur le select()

          et donc ca permet soit de dormir un petit moment, soit d'attendre sur un descripteur de fichier ( idem que read bloquant avec timeout ) ....

          Evidemment, sur un fichier normal, oui, ca sert a rien, mais sur une socket par exemple, c'est tout différent !

      • [^] # Re: Modification du timer du noyau 2.4

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

        Il s'agit effectivement d'un while avec un read dedans, et des tests conditionnels.

        La fonction doit être remplacé dans les jours qui viennent.

        code34

Suivre le flux des commentaires

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