Taskset non funziona su un intervallo di core in isolcpus

Come prefazione sto usando Debian Wheezy con il kernel 3.2 su un chipset AMD64. La mia macchina ha due core Xeon E5-2690. Ho impostato i parametri di avvio in modo che tutti i core su una CPU siano dedicati a un singolo processo. Per fare ciò ho impostato isolcpus = 8,9,10,11,12,13,14,15 in grub.

Fin qui tutto bene. Ora diciamo che voglio usare le CPU isolate per un dato comando, per essere semplice userò solo un semplice ciclo infinito:

$ tasket -c 8-15 bash -c 'mentre vero; do echo hello> / dev / null; fatto' &

Fin qui tutto bene, top mostra che il core 8 gira fino a un utilizzo vicino al 100%. Ora diciamo che lancio di nuovo quel comando:

$ tasket -c 8-15 bash -c 'mentre vero; do echo hello> / dev / null; fatto' &

Ora la parte superiore mostra che i core 9-15 rimangono inattivi e che i due processi condividono il core 8. Se invece lo faccio:

$ tasket -c 8 bash -c 'mentre vero; do echo hello> / dev / null; fatto' &

$ tasket -c 9 bash -c 'mentre vero; do echo hello> / dev / null; fatto' &

I core 8 e 9 ottengono ciascuno il 100% di utilizzo come dovrebbero. Questo vale solo per isolcpus perché lo stesso set di attività con i core 1-7 distribuisce correttamente i processi sui relativi core. Inoltre "tasket -p" mostra che la maschera di affinità per i processi 8-15 è impostata correttamente. Sembra che lo scheduler del kernel si rifiuti di usare qualsiasi cosa tranne il core più basso specificato su una maschera di affinità isolcpus.

Ora normalmente questo non sarebbe un grosso problema con i miei esempi precedenti, basta specificare i singoli core per ogni processo. Tuttavia, voglio eseguire un'applicazione altamente multithread sulla CPU dedicata. Voglio specificare il set di core e utilizzare automaticamente il pool di thread, senza dover reimpostare singolarmente l'affinità del processore per ogni singolo thread generato.

Qualcuno ha idea di come ottenere lo scheduler per darmi più di un core dal set isolcpu?

— user79126
fonte

puoi provare a usare un programma multithread? bash non è multithread

— c4f4t0r

Sì, questo è ciò che mi ha fatto notare in origine (il mio programma multithread non utilizzava più di un core). Un semplice script Python che crea molti thread non riesce a utilizzare più di un core quando viene eseguito sul set isolcpus. (Quando viene eseguito su core non isolati, utilizza tutti gli 8 core disponibili).

— user79126

leggi questo linuxtopia.org/online_books/linux_kernel/kernel_configuration/… , questo esclude un cpus dallo scheduler del kernel, ma dopo aver escluso cpus vuoi eseguire il processo sul cpus escluso?

— c4f4t0r,

Il kernel non pianificherà un thread o un processo su isolcpu a meno che la maschera di affinità del processore non indichi che dovrebbe essere usato. Altrimenti isolcpus sarebbe lo stesso di spegnere il core, quando lo scopo è di riservare un core per un motivo specificato dall'utente e assicurarsi che nessun processo indesiderato lo usi. Taskset imposta la maschera di affinità per usare tutti i core nell'intervallo 8-15 (che è impostato correttamente quando si fa il check in / proc) quindi il kernel dovrebbe programmare il processo sui core inattivi.

— user79126

Dopo una giornata di frustrazione ho deciso una soluzione. Questo comportamento sembra essere un artefatto dell'algoritmo scheduler del kernel predefinito (SCHED_OTHER per questa distribuzione / kernel). La modifica del processo in un algoritmo diverso elimina il problema, isolcpus viene adeguatamente utilizzato in tutti i processi / thread.

Ho finito per usare SCHED_RR, ma ho anche provato SCHED_FIFO e SCHED_IDLE, che sembrano funzionare entrambi. Il processo può essere avviato con l'algoritmo alternativo mediante l'utilità chrt:

$ sudo chrt -r 1 [comando]

(Se si desidera eseguire come non root, è possibile utilizzare l'utilità setcap per abilitare CAP_SYS_NICE sul file binario relativo al comando)

— user79126
fonte

Sebbene il tasketting dell'affinità con i core 0,1 la mia applicazione java utilizzava solo il primo core. 'sudo chrt -r 1 [comando]' ha risolto anche il mio problema.

— Barry NL,