Comment augmenter la priorité des threads dans pthreads ?

Question

J'utilise pthread sous Linux. Je voudrais augmenter la priorité des threads en définissant les paramètres suivants sched_param.priority . Cependant, je n'ai pas trouvé beaucoup d'informations sur le net concernant l'étendue de la priorité des fils que je peux définir, ou sur la description de la priorité des fils.

J'aimerais également connaître la priorité relative des threads car je ne voudrais pas que la priorité des threads soit trop élevée et que le système d'exploitation s'arrête. Quelqu'un pourrait-il m'aider à ce sujet ?

Answer 1

La politique d'ordonnancement par défaut de Linux est SCHED_OTHER qui n'ont pas d'autre choix prioritaire qu'une nice à modifier à l'intérieur de la politique.

Vous devrez changer pour un autre politique de planification en utilisant la fonction pthread_setschedparam (voir aussi man sched_setscheduler )

Politiques d'ordonnancement "normales" : (de sched_setscheduler(2) )

   SCHED_OTHER   the standard round-robin time-sharing policy;
   SCHED_BATCH   for "batch" style execution of processes; and
   SCHED_IDLE    for running very low priority background jobs.

Politiques d'ordonnancement en temps réel :

   SCHED_FIFO    a first-in, first-out policy; and
   SCHED_RR      a round-robin policy.

Dans votre cas, vous pouvez peut-être utiliser SCHED_BATCH car cela ne nécessite pas les privilèges de Root.

Attention : Une mauvaise utilisation des politiques de planification en temps réel peut bloquer votre système. C'est pourquoi vous avez besoin des privilèges de Root pour effectuer ce type d'opération.

Juste pour être sûr de ce que votre machine est capable de faire, vous pouvez utiliser chrt outil de util-linux paquet.
A titre d'exemple :

$ chrt -m 
SCHED_OTHER min/max priority    : 0/0
SCHED_FIFO min/max priority     : 1/99
SCHED_RR min/max priority       : 1/99
SCHED_BATCH min/max priority    : 0/0
SCHED_IDLE min/max priority     : 0/0

Un moyen de déchets moins de temps (ce que j'utilise souvent) :

alias batchmake='time chrt --batch 0 make --silent'

Tout en restant dans le cadre des privilèges de l'utilisateur, cela propulse la make de 15% (dans mon cas).

Editar: présentation de nice , SCHED_BATCH , SCHED_IDLE y chrt outil. Pour la précision ! :)

Answer 2

La réponse actuelle de levif (qui recommande SCHED_BATCH) n'est pas correcte pour l'implémentation actuelle des threads NPTL sous Linux (vous pouvez vérifier l'implémentation de votre noyau en exécutant 'getconf GNU_LIBPTHREAD_VERSION').

Dans le noyau actuel, seules les politiques d'ordonnancement en temps réel permettent de définir la valeur de sched_priority - elle est toujours égale à 0 pour les politiques non-RT (SCHED_OTHER, SCHED_BATCH, et SCHED_IDLE). Votre seul choix pour les politiques non-RT est de définir des valeurs "agréables", par exemple par setpriority(). Il n'y a pas de bonnes spécifications sur le comportement exact à attendre en définissant 'nice' cependant, et cela varie d'une version du noyau à l'autre. Pour les noyaux Linux actuels, 'nice' a un effet très fort similaire à celui de la priorité, et vous pouvez donc l'utiliser de manière interchangeable. Afin d'augmenter la fréquence d'ordonnancement de votre thread, vous voulez inférieur votre valeur "sympa". Cela nécessite la capacité CAP_SYS_NICE (typiquement Root, mais pas nécessairement, cf. http://man7.org/linux/man-pages/man7/capabilities.7.html y http://man7.org/linux/man-pages/man3/cap_set_proc.3.html ).

En fait, SCHED_BATCH est conçu pour la en face de à ce que l'auteur de la question a demandé : il est conçu pour des travaux longs et intensifs en termes de CPU, qui peuvent s'accommoder d'un certain nombre d'inconvénients. inférieur priorité. Elle indique à l'ordonnanceur de pénaliser légèrement la priorité de réveil des threads.

Aussi, pour répondre à l'un des commentaires précédents (je n'ai pas encore une réputation suffisante pour commenter en réponse - quelques votes positifs pour cette réponse aideraient :) ). Oui, la mauvaise nouvelle est que la spécification POSIX.1 indique que "nice" affecte les processus, et non les threads individuels. La bonne nouvelle, c'est que les implémentations de threads de Linux (NTPL et les threads Linux originaux) enfreignent la spécification et lui permettent d'affecter les threads individuels. Je trouve amusant que cela soit souvent signalé dans la section "BUGS" des pages de manuel. Je dirais que le bogue se trouve dans la spécification POSIX.1, qui aurait dû permettre ce comportement, et non dans les implémentations qui ont été contraintes de le fournir en dépit de la spécification et l'ont fait sciemment et délibérément. En d'autres termes, il ne s'agit pas d'un bogue.

La plupart de ces éléments sont détaillés dans la page de manuel sched(7) (qui pour une raison quelconque n'est pas livrée sur mon système Fedora 20) : http://man7.org/linux/man-pages/man7/sched.7.html

Si vous vouliez vraiment influer sur la priorité de la planification, vous pourriez examiner les politiques en temps réel telles que SCHED_RR).

Answer 3

POSIX définit une requête, de sorte que vous pouvez demander à OS la gamme valide des priorités.

int sched_get_priority_max(int policy);

int sched_get_priority_min(int policy);

Ne vous attendez pas à ce que la priorité élevée étouffe la machine. En fait, ne vous attendez pas à ce qu'elle fasse quoi que ce soit à moins que vous n'utilisiez déjà 100% des cycles du CPU. Ne soyez pas surpris si la requête vous dit qu'il n'y a pas de priorité supérieure à celle par défaut.