Comment augmenter la priorité des threads dans pthreads?

Question

J'utilise pthread sous Linux. Je voudrais augmenter la priorité de fil en définissant les paramètres sched_param.priority. Cependant, je n'ai pas pu trouver beaucoup d'informations du net concernant la plage de la priorité de thread que je pourrais définir, ou à propos de la description de la priorité de thread.

En outre, je voudrais connaître la priorité relative des threads car je ne voudrais pas que la priorité des threads soit trop élevée et que l'OS soit stoppé. Quelqu'un pourrait-il m'aider avec ça?

Answer 1

La politique de programmation Linux par défaut est SCHED_OTHER, qui n'a pas de choix de priorité mais un niveau nice à modifier dans la politique.

Vous devrez passer à une autre politique d'ordonnancement en utilisant la fonction pthread_setschedparam (voir aussi man sched_setscheduler)

politiques de planification 'normale': (à partir 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 de planification 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 de privilèges root.

Avertissement: Une mauvaise utilisation des stratégies de planification en temps réel peut bloquer votre système. C'est pourquoi vous avez besoin des privilèges root pour effectuer ce type d'opération. Pour être sûr de ce que votre machine est capable de faire, vous pouvez utiliser l'outil chrt du paquet util-linux.
À 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 

Une façon de déchets moins de temps (que j'utilise souvent):

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

Tout en restant avec les privilèges de l'utilisateur, ce propulse le make de 15% (dans mon Cas).

Edit: introduction nice, SCHED_BATCH, SCHED_IDLE et chrt outil. Pour Precision ! :)

Answer 2

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

int sched_get_priority_max(int policy);

int sched_get_priority_min(int policy);

Ne vous attendez pas à étouffer la priorité soulevé la machine. En fait, ne vous attendez pas à ce qu'il fasse quoi que ce soit, sauf si vous utilisez déjà 100% des cycles du processeur. Ne soyez pas surpris si la requête vous indique qu'il n'y a pas de priorité supérieure à la valeur par défaut.

Answer 3

La réponse actuelle de levif (recommandant SCHED_BATCH) n'est pas correcte pour l'implémentation de threads NPTL sous Linux (vous pouvez vérifier quelle implémentation votre noyau exécute 'getconf GNU_LIBPTHREAD_VERSION').Dans le noyau d'aujourd'hui, seules les politiques de planification en temps réel permettent de définir sched_priority - toujours 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 de «bonnes» valeurs, par ex. par setpriority(). Cependant, il n'y a pas de bonnes spécifications du comportement exact à attendre en définissant 'nice', et au moins en théorie cela pourrait varier de la version du noyau à la version du noyau. Pour les noyaux Linux actuels, 'nice' a un effet très fort similaire à la priorité, donc vous pouvez l'utiliser de façon presque interchangeable. Afin d'augmenter la fréquence à laquelle votre thread est planifié, vous voulez plus bas votre «belle» valeur. Cela nécessite CAP_SYS_NICE (généralement root, mais pas nécessairement, voir http://man7.org/linux/man-pages/man7/capabilities.7.html et http://man7.org/linux/man-pages/man3/cap_set_proc.3.html).

En fait SCHED_BATCH est conçu pour le opposé cas à ce que le questionneur a demandé: il est conçu pour des emplois à long CPU à forte intensité, en cours d'exécution, qui peut vivre avec une priorité inférieure . Il indique au planificateur de pénaliser légèrement la priorité de réveil pour les threads.

Aussi pour répondre à l'un des commentaires précédents (je n'ai pas encore la réputation suffisante pour commenter en réponse - quelques upvotes pour cette réponse aiderait :)). Oui, la mauvaise nouvelle est que la spécification POSIX.1 indique que 'nice' affecte les processus, pas les threads individuels. La bonne nouvelle est que les implémentations de thread Linux (à la fois NPTL et les threads Linux d'origine) enfreignent la spécification et lui permettent d'affecter des threads individuels. Je trouve amusant que cela soit souvent appelé dans la section "BUGS" des pages man. Je dirais que le bogue était dans la spécification POSIX.1, qui aurait dû permettre ce comportement, pas dans les implémentations qui ont été obligées de le fournir malgré la spécification et l'ont fait sciemment et délibérément. En d'autres termes - pas un bug.

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

Si vous voulez vraiment affecter sched_priority vous pouvez regarder le Politiques en temps réel telles que SCHED_RR).