modifier ordonnancement : sched_setpolicy

Citation:

---

Envoyé par hegros

Un thread qui s'execute quand les ressources sont disponibles ? Mais cela est le rôle de l'os qui le gére.

Est-ce que tu as un schéma parlant qui synthétise ce que tu veux faire parce qu'avec les mots à priori tu es difficilement compréhensible.

---

Sauf que entre plusieurs thread de même type l'os ne sait pas qui à le plus besoin de ressources
Je travaille sur un programme dont les thread ont étés crées avec des options par défauts (SCHED_OTHER) et dont on ne peut pas régler la priorité, ni être moins prioritaire à ce que je sache (enfin c'était ma question). Et il est important qu'ils ne soient pas ralentit par le nouveau thread que j'implémente et qui demande beaucoup de temps de calcul.
Et il serait lourd de changer tout ça, à moins de les régler en SCHED_FIFO, ou SCHED_RR avec une priorité qui fasse qu'ils se comportent exactement de la même manière qu'en SCHED_OTHER ?

Citation:

---

Envoyé par Médinoc

On appelle ça la priorité des threads.

• Sous nux, je sais que les processus peuvent avoir différents niveaux de priorité (commande et fonction nice, plus c'est bas plus c'est prioritaire), mais j'ignore ce qu'il en est pour les différents threads d'un processus.

---

La commande nice agit sur les "process" et pas sur les thread, donc ses options de priorités je ne peux pas y avoir accés dans les thread que je crée à l'intérieur du programme (process) principal.

Citation:

---

Envoyé par pasdeface

Et il serait lourd de changer tout ça, à moins de les régler en SCHED_FIFO, ou SCHED_RR avec une priorité qui fasse qu'ils se comportent exactement de la même manière qu'en SCHED_OTHER ?

---

Un thread SCHED_FIFO, par définition, garde la main tant qu'il ne s'endort pas, ou tant qu'un autre thread de priorité supérieure ne se réveille pas. Un thread SCHED_RR, par définition, ne passe pas la main à un thread de priorité inférieure tant qu'il ne s'endort pas - mais il passe la main automatiquement à un thread d'égale priorité.

Si tu as ne serais-ce qu'un seul thread temps-réel, il va avoir la priorité sur tous les autres threads (non TR), donc tous les programmes non TR.

Cela inclus ton shell, ton émulateur de console (à moins que tu utilise une console virtuelle, évidemment), et X (et très probablement tous les programmes tournant sur ton ordinateur), à moins de leurs donner aussi des priorités TR.

C'est à dire que si ton programme part en boucle infinie, tu ne pourra pas l'arrêter avec ^C ou ^Z, parce que l'émulateur n'aura pas la main, et que de toutes façon X non plus, alors aucun "KeyDown" ne sera envoyé (à moins d'être sur une console virtuelle, bien sûr). Tu ne pourra pas non le tuer à distance depuis un autre ordinateur, parce que les démons telnet ou ssh n'auront plus la main non plus.

Citation:

---

Envoyé par pasdeface

La commande nice agit sur les "process" et pas sur les thread, donc ses options de priorités je ne peux pas y avoir accès dans les thread que je crée à l'intérieur du programme (process) principal.

---

D'ailleurs, nice ne fixe pas les priorités, mais des nice-value, ce qui n'a rien à voir.

Citation:

---

Envoyé par corrector

Si tu as ne serais-ce qu'un seul thread temps-réel, il va avoir la priorité sur tous les autres threads (non TR), donc tous les programmes non TR.

Cela inclus ton shell, ton émulateur de console (à moins que tu utilise une console virtuelle, évidemment), et X (et très probablement tous les programmes tournant sur ton ordinateur), à moins de leurs donner aussi des priorités TR.

---

Je penses que c'est pour ça que les autre thread n'ont pas étés crées en temps réel.
Donc Je n'ai aucune solution pour garder ces autres thread en SCHED_OTHER (et donc éviter les problèmes que tu viens de citer) mais qu'ils ne soient pas génés par mon nouveau thread perso ?

Citation:

---

Envoyé par pasdeface

Je penses que c'est pour ça que les autre thread n'ont pas étés crées en temps réel.
Donc Je n'ai aucune solution pour garder ces autres thread en SCHED_OTHER (et donc éviter les problèmes que tu viens de citer) mais qu'ils ne soient pas génés par mon nouveau thread perso ?

---

Le temps réel est censée servir à avoir un temps de réponse "garanti", "sans latences" (mais attention, sous un OS non TR, il n'y a en fait absolument aucune garantie).

En gros, ça te permets de jouer de la musique sans interruption, ou de graver un CD.

Tu n'y trouveras pas ton bonheur (AMA).

Citation:

---

Envoyé par pasdeface

Sauf que entre plusieurs thread de même type l'os ne sait pas qui à le plus besoin de ressources
Je travaille sur un programme dont les thread ont étés crées avec des options par défauts (SCHED_OTHER) et dont on ne peut pas régler la priorité, ni être moins prioritaire à ce que je sache (enfin c'était ma question). Et il est important qu'ils ne soient pas ralentit par le nouveau thread que j'implémente et qui demande beaucoup de temps de calcul.

---

ce n'est toujours pas clair pour moi quand tu dis que tu ne veux pas que les threads existants soient ralentis par l'execution du nouveau thread alors que celui-là consomme beaucoup de calcul. en ajoutant une tâche forcément tu as un ralentissement qui lui est relatif d'autant plus visible si la tâche est lourde comme tu sembles le dire.

Citation:

---

Envoyé par pasdeface

Et il serait lourd de changer tout ça, à moins de les régler en SCHED_FIFO, ou SCHED_RR avec une priorité qui fasse qu'ils se comportent exactement de la même manière qu'en SCHED_OTHER ?

---

je pensais que tu ne pouvais pas modifier les paramètres d'environnement des threads existants ?

Citation:

---

Envoyé par hegros

ce n'est toujours pas clair pour moi quand tu dis que tu ne veux pas que les threads existants soient ralentis par l'execution du nouveau thread alors que celui-là consomme beaucoup de calcul. en ajoutant une tâche forcément tu as un ralentissement qui lui est relatif d'autant plus visible si la tâche est lourde comme tu sembles le dire.

---

Oui pardon, j'aurai dû préciser qu'elle est lourde mais pas en permanence.
Donc je voudrais que quand je la lance elle prenne plus de temps à s'exécuter si les autres tâches ont besoin de ressources.

Citation:

---

je pensais que tu ne pouvais pas modifier les paramètres d'environnement des threads existants ?

---

Je ne peux pas le faire moi même pour l'instant, mais ça aurait pu être envisagé si c'est la seule solution et qu'elle est faisable.

Citation:

---

Envoyé par hegros

ce n'est toujours pas clair pour moi quand tu dis que tu ne veux pas que les threads existants soient ralentis par l'execution du nouveau thread alors que celui-là consomme beaucoup de calcul. en ajoutant une tâche forcément tu as un ralentissement qui lui est relatif d'autant plus visible si la tâche est lourde comme tu sembles le dire.

---

Non, pas si la tache en question a une "gentillesse" (ou politesse?) - je veux dire nice-value - supérieure à celle des autres, alors elle ne doit pas (trop) ralentir les autres taches moins "gentilles".

Ceci dit, il y a interaction via le working set/le swap, qui n'est pas contrôlable par "nice" (pas contrôlable du tout sur les Un*x que les connais) : si un programme utilise beaucoup de mémoire, elle va faire swaper les autres (cf. l'écroulement des performances lors du passages de slocate et co. à 4h du matin ;) ).