Perché il livello di Nizza viene ignorato? (tra sessioni di accesso diverse:onorato se avviato dalla stessa sessione.)?

Quando avvio due processi che consumano CPU con diversi livelli piacevoli, ad es.

Processo 1:

nice -19 sh -c 'while true; do :; done'

Processo 2:

sh -c 'while :; do true; done'

(Ho cambiato l'ordine di : e true solo per distinguere i processi negli output di ps o top ),

il livello piacevole sembra essere ignorato ed entrambi utilizzano la stessa quantità di CPU.

L'output di top è come

  PID USER      PR  NI    VIRT    RES %CPU %MEM     TIME+ S COMMAND
 8187 <user>    39  19   21.9m   3.6m 45.8  0.0   0:20.62 R sh -c while true; do :; done
 8188 <user>    20   0   21.9m   3.5m 45.6  0.0   0:20.23 R sh -c while :; do true; done
 [...]

(ovviamente, la %CPU -i valori variano leggermente da campione a campione, ma in media sembrano uguali).

top mostra che entrambi i processi vengono eseguiti con valori piacevoli diversi, ma sembrano comunque ottenere la stessa quantità di tempo CPU.

Entrambi i comandi sono stati eseguiti dallo stesso utente da terminali diversi (entrambi sono shell di login).

Se vengono eseguiti dallo stesso terminale, si comportano come previsto:il processo più piacevole lascia il posto a quello meno piacevole.

Qual è il motivo? Come fare un bel lavoro a livello globale sull'intera macchina?

Era diverso su quella stessa macchina qualche tempo prima, dove i bei valori sembravano essere rispettati.

È una macchina a processore singolo/single core.

Per informazioni:

• Kernel:versione 4.4.5 (kernel stock Arch Linux); uname -r :4.4.5-1-ARCH ,

• /proc/cpuinfo è:

  processor       : 0
  vendor_id       : GenuineIntel
  cpu family      : 6
  model           : 23
  model name      : Intel(R) Core(TM)2 Solo CPU    U3500  @ 1.40GHz
  stepping        : 10
  microcode       : 0xa0c
  cpu MHz         : 1400.000
  cache size      : 3072 KB
  physical id     : 0
  siblings        : 1
  core id         : 0
  cpu cores       : 1
  apicid          : 0
  initial apicid  : 0
  fpu             : yes
  fpu_exception   : yes
  cpuid level     : 13
  wp              : yes
  flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority
  bugs            :
  bogomips        : 2794.46
  clflush size    : 64
  cache_alignment : 64
  address sizes   : 36 bits physical, 48 bits virtual
  power management:
  

Risposta accettata:

Ah, non è la funzione systemd-logind in cui ogni utente ottiene il proprio cgroup. Penso che il cambiamento responsabile qui sia più vecchio; sono solo confusamente simili. (Ho cercato "programmazione equa del gruppo di processi", pensando che potesse essere qualcosa basato sui "gruppi di processi" di Unix che non ho mai veramente capito). Wikipedia:

Il kernel Linux ha ricevuto una patch per CFS nel novembre 2010 per il kernel 2.6.38 che ha reso lo scheduler più equo per l'uso su desktop e workstation.

Quando un'attività chiama __proc_set_tty(), il riferimento a livello di processo al gruppo predefinito viene eliminato, viene creato un nuovo gruppo di attività e il processo viene spostato nel nuovo gruppo di attività. I bambini in seguito ereditano questo gruppo di attività e ne aumentano il rifcount. All'uscita, un riferimento al gruppo di attività corrente viene eliminato quando viene eliminato l'ultimo riferimento a ciascuna struttura di segnale. Il gruppo di attività viene distrutto quando viene liberata l'ultima struttura di segnale che fa riferimento ad esso. Al momento della selezione della coda di esecuzione, IFF un'attività non ha assegnazione cgroup, viene utilizzato il suo autogroup corrente.

La funzione è abilitata dall'avvio per impostazione predefinita se è selezionato CONFIG_SCHED_AUTOGROUP, ma può essere disabilitata tramite l'opzione di avvio noautogroup e può anche essere attivata/disattivata al volo [tramite /proc/sys/kernel/sched_autogroup_enabled :Scrittura di lì lo disabilita per le attività appena create, scrivendo 1 lo abilita.]

I problemi principali risolti in questo modo riguardano i sistemi multi-core e multi-cpu (SMP) che sperimentano tempi di risposta interattivi aumentati durante l'esecuzione di altre attività che utilizzano molti thread in tali attività. Una semplice spiegazione è che si sarà ancora in grado di guardare un video, leggere e-mail ed eseguire altre attività tipiche del desktop senza problemi o discontinuità durante la compilazione del kernel Linux o un processo simile come la codifica di video. Tuttavia, ci sono obiezioni a questa affermazione.