Come eseguire i processi convogliati con bash su più core?

Question

Ho un semplice script di bash che canalizza l'output di un processo in un altro. Vale a dire :.

dostuff | filterstuff 

Accade che sul mio sistema Linux (openSUSE se è importante, il kernel 2.6.27) questi due processi eseguito su un singolo core. Tuttavia, l'esecuzione di diversi processi su diversi core è una norma predefinita che non si verifica in questo caso.

Quale componente del sistema è responsabile di ciò e cosa devo fare per utilizzare la funzionalità multicore?

Nota che non c'è alcun problema sul kernel 2.6.30.

Chiarimento: Dopo aver seguito Dennis Williamson 's consigli, ho fatto sicuro con il programma top, che in filodiffusione processi sono infatti sempre corsa sullo stesso processore. Programmatore di Linux, che di solito fa un ottimo lavoro, questa volta non lo fa.

Immagino che qualcosa in bash impedisca al sistema operativo di farlo. Il fatto è che ho bisogno di una soluzione portatile per macchine multi-core e single-core. Il tasksetsolution proposto da Dennis Williamson non funziona su macchine single-core. Attualmente sto usando :,

dostuff | taskset -c 0 filterstuff 

ma questo sembra un hack sporco. Qualcuno potrebbe fornire una soluzione migliore?

Answer 1

Supponiamo che dostuff sia in esecuzione su una CPU. Scrive i dati in una pipe e tali dati si troveranno nella cache su quella CPU. Poiché filterstuff sta leggendo da quella pipe, lo scheduler decide di eseguirlo sulla stessa CPU, in modo che i suoi dati di input siano già nella cache.

Se il kernel è stato compilato con CONFIG_SCHED_DEBUG=y,

# echo NO_SYNC_WAKEUPS > /sys/kernel/debug/sched_features

dovrebbe disabilitare questa classe di euristiche. (Vedere /usr/src/linux/kernel/sched_features.h e /proc/sys/kernel/sched_* per altri parametri sintonizzabili dello scheduler.)

se questo aiuta, e il problema si verifica ancora con un kernel più recente, e è davvero più veloce di girare su CPU separati di una CPU, si prega di segnalare il problema alla Mailing List Linux Kernel in modo che possano regolare il loro euristico.

Answer 2

dare una prova per impostare la CPU (processore) affinità:

taskset -c 0 dostuff | taskset -c 1 filterstuff 

Edit:

Prova questo esperimento:

• creare un file chiamato ProcTest e chmod +x proctest con questo come il contenuto:

  #!/bin/bash 
  while true 
  do 
      ps 
      sleep 2 
  done 
  

• Iniziamo questo correre:

  ./proctest | grep bash 
  

• in un altro terminal, avviare top - assicurarsi che sia l'ordinamento per% CPU
• lasciate riposare per alcuni secondi, quindi chiudere
• eseguire il comando ps u

• start top -p con un elenco di PID dei più alti processi diversi, ad esempio 8 di essi, dall'elenco a sinistra sullo schermo dall'uscita top oltre a quelli per proctest e grep iscritte da ps - separate da virgola, in questo modo (l'ordine non importa):

  top -p 1234, 1255, 1211, 1212, 1270, 1275, 1261, 1250, 16521, 16522 
  

• aggiungere il campo processore - premere f poi j poi spazio
• impostare il tipo di PID - stampa Maiusc +F poi un poi Spazio
• opzionale: pressa Maiusc + H per attivare la visualizzazione filo
• opzionale: pressa d e digitare .09 e premere Invio di impostare un breve intervallo di tempo
• ora guardare come processi mossa dal processore al processore, dovresti vedere proctest e grep rimbalzare, a volte sullo stesso processore, a volte su quelli diversi

Answer 3

Lo scheduler di Linux è progettato per fornire il massimo rendimento, non fare ciò che si immagina sia il migliore. Se stai eseguendo processi connessi a una pipe, con ogni probabilità uno di questi blocca l'altro, allora si scambiano. Eseguirli su core separati otterrebbe poco o nulla, quindi non lo fa.

Se si dispone di due task che sono entrambi realmente pronti per l'esecuzione sulla CPU, mi aspetto di vederli pianificati su diversi core (ad un certo punto).

La mia ipotesi è, quello che succede è che il dostuff viene eseguito fino a quando il buffer di pipe diventa pieno, a quel punto non può più funzionare, quindi il processo "filterstuff" viene eseguito, ma funziona per un tempo così breve che dostuff non viene ripianificato fino a quando filtertuff ha finito di filtrare l'intero buffer di pipe, dopodiché il dostuff viene nuovamente programmato.