Forum Linux.noyau SCHED_FIFO et signal alarme

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
2
1
jan.
2019

Bonjour à tous

je dispose d'un processeur quad-core.
je veux faire planter mon ordi en infectant a chaque processeur un processus avec une priorité maximale et avec comme politique d'ordonnancement SCHED_FIFO. Donc des que le noyau affecte mon processus a un processeur, le processus ne rend jamais la main.
voici mon code:

    int main(void)
    {       
        struct sched_param schedParam;
        schedParam.sched_priority = 99;

        if ( sched_setscheduler(getpid(), SCHED_FIFO, & schedParam) != 0)
        {
            fprintf(stdout, "error scheduler\n");
        }

        //alarm(20);
        while(1);

        return 0;
    }

je lance sur un terminal:
sleep 10; tasket -c 0 ./a.out
puis sur un autre
sleep 10; tasket -c 1 ./a.out
puis sur un autre
sleep 10; tasket -c 2 ./a.out
puis sur un autre
sleep 10; tasket -c 3 ./a.out

et au bout de 10 secondes tout les processus sont en RUN sur chacun de mes processeurs et mon ordi plante, je ne peux plus rien faire. Objectif réussi :)

Puis dans un second temps je dé-commente //alarm(20); de mon programme.

et la au bout de 20 seconde de plantage, le noyau détruit les processus et je peux de nouveau utiliser mon ordinateur sans devoir le redémarrer.
Mais l'instruction alarm(20) indique au noyau d'envoyer un signal au processus. Mais comment le noyau peut continuer a faire des choses alors que tous les processeurs sont utilisés et que les processus avec la politique d’ordonnancement que j'ai initialisé, interdit a aucun autre processus de prendre la main y compris le noyau non ??

voila je reconnais que c'est un peu long, et je vous remercie par avance pour vos éclaircissements.

  • # preempt

    Posté par  . Évalué à 4.

    SCHED_FIFO ne dit pas que le kernel ne va jamais reprendre la main. N'importe quel thread avec une priorité plus élevée peut le préempter, et il doit avoir un thread kernel out deux avec une priorité plus élevée que ton processus.

    http://man7.org/linux/man-pages/man7/sched.7.html

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: preempt

      Posté par  . Évalué à 1.

      la priorité max sur linux c'est 99. donc techniquement rien ne peut préempter les processus que je lance

      • [^] # Re: preempt

        Posté par  . Évalué à 4.

        Sauf certains jobs kernel (dont le schedulling) qui ont toujours une priorité plus élevée que l'userspace.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: preempt

          Posté par  . Évalué à 1.

          Merci pour tes reponses, je n'y connais rien au noyau, mais est ce que le noyau à un pid ou c'est plus compliqué que ca ?

          • [^] # Re: preempt

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

            Non le noyau n'a pas de PID car par définition ce n'est pas un processus. Certaines tâches du noyau peuvent être exécutées avec des threads ayant un PID mais cela ne concerne pas le cœur du noyau dont fait parti l'ordonnanceur.

            Dans ce contexte le noyau a toujours la main de temps en temps. En effet, pour diverses raisons le processeur reçoit ou génère des interruptions que le noyau doit traiter (paquet réseau reçu, touche du clavier saisie, fichiers venant du disque dur reçu, etc.). Cela appelle automatiquement des fonctions du noyau (via le vecteur d'interruptions) qui les traite.

            Même dans le cadre d'un ordonnancement FIFO, le noyau se réveille de temps en temps pour vérifier qu'il n'y a rien à faire, mais aussi pour vérifier si le processus en cours d'exécution est bien celui qui doit être exécuté maintenant. Car si par exemple un processus avec une priorité plus haute est disponible, il doit remplacer celui en cours d'exécution par exemple.

            Et en l’occurrence le noyau traite les signaux ou les alarmes à destination de ton processus.

Suivre le flux des commentaires

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