Come aumentare la priorità del thread in pthreads?

Sto usando pthread in Linux. Vorrei aumentare la priorità del thread impostando i parametri sched_param.priority . Tuttavia, non sono riuscito a trovare molte informazioni dalla rete riguardo all’intervallo della priorità del thread che potevo impostare, o alla descrizione della priorità del thread.

Inoltre, vorrei conoscere la priorità del thread relativo in quanto non vorrei impostare la priorità del thread troppo alta e il conseguente arresto del sistema operativo. Qualcuno potrebbe aiutarmi con questo?

Il criterio di pianificazione Linux predefinito è SCHED_OTHER , che non ha una scelta prioritaria ma un nice livello da modificare all’interno della politica.

Dovrai passare ad un altro criterio di pianificazione usando la funzione pthread_setschedparam (vedi anche man sched_setscheduler )

Criteri di pianificazione “normali”: (da 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. 

Politiche di pianificazione in tempo reale:

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

Nel tuo caso, forse puoi utilizzare SCHED_BATCH quanto non richiede i privilegi di root.

Avvertenza: l’ utilizzo errato delle politiche di pianificazione in tempo reale potrebbe bloccare il sistema. Ecco perché hai bisogno dei privilegi di root per fare questo tipo di operazione.

Per essere sicuri di ciò che è in grado di fare con la tua macchina, puoi usare chrt tool dal util-linux .
Come esempio:

 $ 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 modo per perdere meno tempo (che uso spesso):

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

Restando con i privilegi degli utenti, questo spinge la make del 15% (nel mio caso).

Modifica: introduzione dello strumento nice , SCHED_BATCH , SCHED_IDLE e chrt . Per precisione! 🙂

L’attuale risposta di levif (raccomandando SCHED_BATCH) non è corretta per l’attuale implementazione del thread NPTL su Linux (puoi verificare quale implementazione ha il tuo kernel eseguendo ‘getconf GNU_LIBPTHREAD_VERSION’).

Nel kernel di oggi solo le politiche di pianificazione in tempo reale consentono l’impostazione di sched_priority – è sempre 0 per i criteri non RT (SCHED_OTHER, SCHED_BATCH e SCHED_IDLE). La tua unica scelta per le polizze non RT è di impostare valori “carini”, ad esempio con setpriority (). Non ci sono buone specifiche del comportamento esatto da aspettarsi impostando ‘nice’ comunque, e almeno in teoria potrebbe variare dalla versione del kernel alla versione del kernel. Per gli attuali kernel di Linux, “nice” ha un effetto molto forte simile alla priorità, quindi puoi usarlo praticamente in modo intercambiabile. Per aumentare la frequenza con cui è pianificata la discussione, si desidera ridurre il valore “bello”. Ciò richiede la capacità CAP_SYS_NICE (in genere root, sebbene non necessariamente, vedere http://man7.org/linux/man-pages/man7/capabilities.7.html e http://man7.org/linux/man-pages/man3 / cap_set_proc.3.html ).

In effetti SCHED_BATCH è progettato per il caso opposto a quello richiesto dall’interrogante: è progettato per i lavori a uso intensivo della CPU, che possono vivere con priorità più bassa . Indica allo scheduler di penalizzare leggermente la priorità di triggerszione per i thread.

Anche per rispondere a uno dei commenti precedenti (non ho ancora una reputazione sufficiente per commentare in risposta – alcuni upvotes per questa risposta aiuterebbero :)). Sì, la ctriggers notizia è che la specifica POSIX.1 dice che “bello” influenza i processi, non i singoli thread. La buona notizia è che le implementazioni dei thread di Linux (sia NPTL che i thread Linux originali) interrompono le specifiche e consentono di influenzare i singoli thread. Trovo divertente che questo sia spesso chiamato nella sezione “BUG” delle pagine man. Direi che il bug era nella specifica POSIX.1, che avrebbe dovuto consentire questo comportamento, non nelle implementazioni che erano state costrette a fornirlo nonostante le specifiche e lo facevano consapevolmente e deliberatamente. In altre parole – non un bug.

La maggior parte di ciò è dettagliata sulla pagina man di sched (7) (che per qualche motivo non viene fornita sul mio sistema Fedora 20): http://man7.org/linux/man-pages/man7/sched.7.html

Se vuoi davvero influenzare sched_priority puoi consultare le politiche in tempo reale come SCHED_RR).

POSIX definisce una query, quindi puoi chiedere al sistema operativo l’intervallo di priorità valido.

int sched_get_priority_max(int policy);

int sched_get_priority_min(int policy);

Non aspettarti che la priorità elevata soffochi la macchina. In effetti, non aspettarti che faccia nulla, a meno che tu non stia già utilizzando il 100% dei cicli della CPU. Non sorprenderti se la query ti dice che non esiste una priorità superiore a quella predefinita.