Il comportamento che si sta vedendo è quasi certamente a causa della funzione di autogroup che è stata aggiunta in Linux 2.6.38 (nel 2010). Presumibilmente quando hai descritto di eseguire i due comandi, sono stati eseguiti in diverse finestre di terminale. Se li avessi eseguiti nella finestra del terminale stessa, avresti dovuto vedere che il bel valore ha un effetto. Il resto di questa risposta elabora la storia.
Il kernel fornisce una funzionalità nota come Autogrouping per migliorare le prestazioni desktop interattivo di fronte multiprocesso, carichi di lavoro intensivo della CPU come la costruzione del kernel Linux con un gran numero di processi di compilazione parallele (cioè la bandiera make(1) -j).
Un nuovo gruppo automatico viene creato quando viene creata una nuova sessione tramite setsid(2); questo accade, ad esempio, quando viene avviata una nuova finestra di terminale. Un nuovo processo creato da fork(2) eredita l'appartenenza al gruppo di auto del genitore genitore. Pertanto, tutti i processi in una sessione sono membri dello stesso gruppo automatico.
Quando il raggruppamento automatico è abilitato, tutti i membri di un gruppo automatico vengono inseriti nello stesso "gruppo di attività" del programma di pianificazione del kernel. Lo scheduler del kernel Linux utilizza un algoritmo che equalizza la distribuzione dei cicli di CPU tra i gruppi di attività. I vantaggi di questo per le prestazioni del desktop interattivo possono essere descritti mediante l'esempio seguente.
Supponiamo che ci sono due autogroups competono per lo stesso CPU (cioè, presume sia un sistema a singola CPU o l'uso di taskset(1) confinare tutti i processi per la stessa CPU su un sistema SMP). Il primo gruppo contiene dieci processi associati alla CPU da un kernel build avviato con make -j10. L'altro contiene un singolo processo basato su CPU : un lettore video. L'effetto del raggruppamento automatico è che a i due gruppi riceveranno ciascuno metà dei cicli della CPU. Cioè, il video player riceverà il 50% dei cicli della CPU, piuttosto che il solo il 9% dei cicli, il che probabilmente porterebbe alla riproduzione video degradata .La situazione su un sistema SMP è più complessa, ma l'effetto generale è lo stesso: lo scheduler distribuisce i cicli di CPU in gruppi di attività in modo che un gruppo di automazioni contenente un numero di grande numero di processi associati alla CPU non finisca per eseguire il ciclo della CPU a scapito degli altri lavori sul sistema.
Il valore bello e la pianificazione di gruppo
Quando si pianifica processi non in tempo reale (ad esempio, quelli previsti nell'ambito della politica di default SCHED_OTHER), lo scheduler impiega una tecnica nota come "la pianificazione di gruppo", sotto quali thread sono programmati in "gruppi di attività". I gruppi di attività sono formati nelle varie circostanze, con il caso pertinente in questo caso di raggruppamento automatico.
Se Autogrouping è abilitata, tutti i fili che sono (implicitamente) poste in un autogroup (cioè la stessa sessione, come creato da setsid(2)) formano un gruppo di lavoro. Ogni nuovo gruppo automatico è quindi un gruppo di attività separato.
Sotto pianificazione di gruppo, il valore nice di un thread ha un effetto per decisioni schedulazione solo relativi ad altri thread nel gruppo di task stesso . Ciò ha alcune sorprendenti conseguenze in termini di semantica tradizionale del valore piacevole sui sistemi UNIX. In particolare, se è abilitato il raggruppamento automatico (che è l'impostazione predefinita in varie distribuzioni Linux), lo su un processo ha solo per la pianificazione relativa ad altri processi eseguiti nella stessa sessione (in genere: la stessa finestra di terminale) .
contrario, per due processi che sono (per esempio) le sole processi legati alla CPU in diverse sessioni (ad esempio, diversi terminali finestre, ciascuna di cui posti di lavoro sono legate a differenti autogroups), modificano il valore nice di il processo in una delle sessioni ha nessun effetto in termini di decisioni dello scheduler relative al processo nell'altra sessione. Questo presumibilmente è lo scenario che hai visto, anche se non menzioni esplicitamente l'uso di due finestre di terminale.
Se si desidera impedire Autoraggruppamento interferire con la tradizionale nice comportamento come descritto qui, è possibile disattivare la funzione
echo 0 > /proc/sys/kernel/sched_autogroup_enabled
essere consapevoli però che questo avrà anche l'effetto di disabilitare i benefici per l'interattività desktop che la funzione gruppo auto era destinata a fornire (vedi sopra).
Il valore nice autogroup
appartenenza autogroup di un processo può essere visualizzato tramite il file /proc/[pid]/autogroup:
$ cat /proc/1/autogroup
/autogroup-1 nice 0
Questo file può anche essere utilizzato per modificare la larghezza di banda della CPU allocata a un autogroup . Questo viene fatto scrivendo un numero nell'intervallo "bello" nel file per impostare il valore piacevole del gruppo di ricerca. L'intervallo consentito è compreso tra +19 (priorità bassa) e -20 (priorità alta).
L'autogroup ambiente piacevole ha lo stesso significato del valore nice processo , ma si applica alla distribuzione di cicli della CPU al autogroup nel suo complesso, sulla base dei valori relativi piacevoli di altre autogroups. Per un processo all'interno di un gruppo automatico, la CPU che riceve sarà un prodotto del valore piacevole del gruppo di ricerca (confrontato con lo in altri gruppi automatici) e il valore piacevole del processo (rispetto a altri processi nello stesso gruppo automatico).
quali sono stati i calcoli? Forse non c'è abbastanza conflitto sul processore per fare la differenza – laher
I calcoli all'interno del ciclo sono abbastanza lunghi. Ho anche controllato l'output assembler generato e nulla è stato ottimizzato (compilato con le impostazioni di ottimizzazione più basse su gcc). –
possibile duplicato di [Understanding renice] (http://stackoverflow.com/questions/22090126/understanding-renice) – ninjalj