Forum Linux.général SCHED_FIFO et non préemptif c'est à dire

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
19
jan.
2018

Bonjour,

pour moi un système préemptif est un système arrête momentanément une tache pour laisser une autre tache plus prioritaire utiliser le CPU. SCHED_FIFO est dite comme non préemptif, donc si je lance un processus de priorité 1, alors meme si un processus de plus haute priorité (par exemple 99) arrive sur la file READY, alors le noyau ne peut pas donné du temps de CPU au processus de priorité 99 car en SCHED_FIFO une fois un processus lancé on doit attendre qu'il s’arrête de lui meme.

Mais je trouve sur le net que SCHED_FIFO est non préemptif mais laisse quand meme sa place au processus de plus haute priorité d'ou le paradoxe avec mon résonnement.

Si quelqu'un pouvait m'éclaircir.

Merci d'avance

  • # Définir non préemptif…

    Posté par  . Évalué à 5. Dernière modification le 19 janvier 2018 à 12:23.

    Je ne sais pas où tu as lu ça, mais je pense que l’idée et de dire que tant qu’aucune tâche de plus haute priorité n’est prête, la tâche ne sera pas interrompue. Même si elle passe 1h à s’exécuter.

    Néanmoins, il n’y a aucun rapport entre préemptif (adj.) et SCHED_FIFO qui est une politique d’ordonnancement. C’est un peu comme dire : « La couleur de ce chat est angora. ».

    Pour résumer, oui un ordonnanceur qui implémente la politique SCHED_FIFO est un ordonnanceur préemptif.
    Fait attention aux sites que tu lis. Certains expliquent des trucs qu’ils croient avoir compris, ça nous arrive à tous, mais quand on publie il faut être plus rigoureux de façon à ne pas induire quelqu’un en erreur.

    Sur ton message précédent, j’ai été volontairement flou sur certains points pour pas te noyer au premier message. Si tu as besoin de précision, n’hésite pas à répondre là où tu as besoin.

    • [^] # Re: Définir non préemptif…

      Posté par  . Évalué à 2. Dernière modification le 19 janvier 2018 à 13:24.

      Merci pour ta réponse.

      d'accord et un processus de priorité 10 et de politique d'ordonnancement SCHED_RR est autant prioritaire qu'un processus de priorité 10 et de politique d'ordonnancement SCHED_FIFO ou les politique d’ordonnancement SCHED_FIFO sont plus prioritaire que SCHED_RR ?

      Je cite (vu sur un site) :
      "L’ordonnanceur gère la file SCHED_FIFO en utilisant la stratégie non préemptive. Il
      choisit d’élire le processus de type SCHED_FIFO le plus prioritaire pour s’exécuter. N’étant
      pas préemptible, ce processus s’exécute jusqu’à la fin sans libération du processeur"
      je retrouve souvent ca, et je bug la dessus car j'ai l'impression de comprendre que le noyau laisse le processus finir sa tache peu importe qu'il y ait des processus de plus grande priorité.

      tu dis :"je pense que l’idée et de dire que tant qu’aucune tâche de plus haute priorité n’est prête, la tâche ne sera pas interrompue. Même si elle passe 1h à s’exécuter" donc le problème de la politique d'ordonnancement SCHED_FIFO c'est que si j'ai deux processus de meme priorité mais avec un processus tres court en temps processeur et l'autre tres lent, alors l'ordonnanceur lance le premier (FIFO) car le processus qui est tres court peut se retrouver en second dans la file READY. Ce qui est différent avec la politique d'ordonnanceur RR qui lui aurait partagé le temps du CPU. Donc le politique SCHED_FIFO peut rendre des systèmes instables car il peut lancer pendant des heures juste un processus (dans le cas ou on a qu'un seul coeur et un seul thread processeur)?

      • [^] # Re: Définir non préemptif…

        Posté par  . Évalué à 2.

        d'accord et un processus de priorité 10 et de politique d'ordonnancement SCHED_RR est autant prioritaire qu'un processus de priorité 10 et de politique d'ordonnancement SCHED_FIFO ou les politique d’ordonnancement SCHED_FIFO sont plus prioritaire que SCHED_RR ?

        Là, tu me poses une colle. Je ne joue pas à ça. À une priorité donnée, je mets soit RR soit FIFO, mais pas les deux. Il faudrait regarder ce qui est marqué dans la norme POSIX. Mais il y a toujours un risque sur l’implémentation sur le système que tu utilises. Quand on passe les tâches en TR, c’est pour gagner en maîtrise, ce n’est pas pour ajouter de l’incertitude. Donc je ne le ferai pas.

        Instinctivement, je dirai que FIFO 10 est plus prioritaire que RR 10, mais moins que RR11. Mais je n’ai jamais essayé de mixer.

        Je cite (vu sur un site) :
        "(…). N’étant
        pas préemptible, ce processus s’exécute jusqu’à la fin sans libération du processeur"

        Il parle de processus de même priorité. C’est pour alerter que les autres tâches n’auront pas de CPU (en multi cœur c’est faux), et que ça peut bloquer l’ordi. Je vois ça plus comme une mise en garde. Mais je t’accorde que c’est imprécis.

        je retrouve souvent ca, et je bug la dessus car j'ai l'impression de comprendre que le noyau laisse le processus finir sa tache peu importe qu'il y ait des processus de plus grande priorité.

        Non, la tâche sera bien interrompu par des tâches plus prioritaire.

        si j'ai deux processus de meme priorité mais avec un processus tres court en temps processeur et l'autre tres lent, alors l'ordonnanceur lance le premier (FIFO) car le processus qui est tres court peut se retrouver en second dans la file READY.

        Je ne sais pas ce que tu veux faire. Le temps réel est quelques chose de particulier. Si tu veux faire de l’applicatif « normal » n’utilise pas. L’objectif du temps réel est de garantir des temps de réponse, pas d’aller vite. Donc toute ton architecture se base sur des euristiques de temps de traitement de chaque tâche, et chaque tâche répond a un stimuli auquel on veut répondre.

        Ex: J’ai une tâche qui surveille la monté d’eau dans un aquarium. Je connais le débit d’eau, la hauteur au dessus de mon capteur, donc je sais déterminer combien de temps il me reste quand le capteur me dit plein. On enlève un peu de temps, il y a potentiellement des remous ou que sais-je.

        À partir de ta cascade d’événements, qui produisent des réponses pouvant être des stimuli d’autres tâches.

        Ce qui est différent avec la politique d'ordonnanceur RR qui lui aurait partagé le temps du CPU. Donc le politique SCHED_FIFO peut rendre des systèmes instables car il peut lancer pendant des heures juste un processus (dans le cas ou on a qu'un seul coeur et un seul thread processeur)?

        Normalement, quand tu mets une tâche en SCHED_FIFO, c’est qu’elle est suffisamment courte.

        • [^] # Re: Définir non préemptif…

          Posté par  . Évalué à 1.

          d'accord donc quand on dit que la politique d'ordonnancement est préemptive (SCHED_RR), ca signigie que pour des processus de meme priorité, on verra ces différents processus se partager le CPU ? donc pour SCHEF_FIFO qui est non préemptive, il y a aucun partage du CPU pour les processus de meme priorité ?

          • [^] # Re: Définir non préemptif…

            Posté par  . Évalué à 3.

            Quand on dit que l’ordonnanceur est préemptif, ça veut dire qu’il peut interrompre une tâche s’il le veut… ou la laisser tourner s’il le veut.
            C’est en opposition à l’ordonnanceur coopératif, ou il faut appeler une fonction spéciale pour être reschedulé, ou certaines fonction de l’OS le font d’eux même.

            L’ordonnanceur à beau être préemptif (capable de préempté la tâche) si tu lui dit explicitement de la laisser tourner, il va le faire. Temps qu’on utilise l’ordonnanceur en temps partagé, tous les thread auront à un moment du temps CPU. En mode Temps Réel, c’est différent. Ce n’est pas à utiliser à la légère. Par exemple, malgré un aspect temps réel sur l’affichage de page internet, et comme ce n’est pas critique, les navigateur web utilise les priorités standard. Ça suffit la plupart du temps, et quand ça suffit pas, ce n’est pas grave.

            Imagine que firefox, utilise des threads temps réel pour rendre une page… et que celle-ci prennent du temps à cause de sa complexité, son javascript… tout ton système serait à la ramasse. C’est pour ça que ce n’est pas utilisé comme ça. C’est moins grave que ça lague un peu, plutôt que ça bloque le système.

            Je ne sais pas ce que tu veux faire, tu ne précises rien. Mais réfléchie bien à si tu en as vraiment besoin… après, si c’est juste des TPs pour appréhender les concepts, alors continue, il n’y a rien de mieux que de ce prendre les pieds dans le tapis pour comprendre qu’il faut les lever ;-)

Suivre le flux des commentaires

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