Pourquoi le niveau de Nice est-il ignoré ? (entre différentes sessions de connexion - honoré si démarré à partir de la même session.) ?

Lorsque je démarre deux processus gourmands en CPU avec différents niveaux de gentillesse, par exemple

Processus 1 :

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

Processus 2 :

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

(J'ai changé l'ordre de : et true juste pour différencier les processus dans les sorties de ps ou top ),

le niveau de gentillesse semble être ignoré et les deux utilisent la même quantité de CPU.

La sortie de top est comme

  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
 [...]

(bien sûr, le %CPU -les valeurs varient légèrement d'un échantillon à l'autre, mais en moyenne, elles semblent égales).

top montre que les deux processus s'exécutent avec des valeurs agréables différentes, mais qu'ils semblent toujours obtenir le même temps CPU.

Les deux commandes ont été exécutées par le même utilisateur à partir de terminaux différents (les deux sont des shells de connexion).

S'ils sont exécutés à partir du même terminal, ils se comportent comme prévu :le processus le plus agréable fait place à celui qui n'est pas si agréable.

Quelle est la raison? Comment faire du bon travail globalement sur toute la machine ?

C'était différent sur cette même machine quelque temps auparavant, où les bonnes valeurs semblaient être honorées.

Il s'agit d'une machine à un seul processeur/un seul cœur.

Pour information :

• Noyau :version 4.4.5 (noyau de base Arch Linux) ; uname -r :4.4.5-1-ARCH ,

• /proc/cpuinfo est :

  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:
  

Réponse acceptée :

Ah, ce n'est pas la fonctionnalité systemd-logind où chaque utilisateur obtient son propre groupe de contrôle. Je pense que le changement responsable ici est plus ancien; ils sont juste confusément similaires. (J'ai cherché "planification équitable des groupes de processus", pensant que cela pourrait être quelque chose basé sur les "groupes de processus" d'Unix que je ne comprends jamais vraiment). Wikipédia :

Le noyau Linux a reçu un correctif pour CFS en novembre 2010 pour le noyau 2.6.38 qui a rendu le planificateur plus juste pour une utilisation sur les ordinateurs de bureau et les postes de travail.

Lorsqu'une tâche appelle __proc_set_tty(), la référence globale du processus au groupe par défaut est supprimée, un nouveau groupe de tâches est créé et le processus est déplacé dans le nouveau groupe de tâches. Les enfants héritent ensuite de ce groupe de tâches et augmentent son refcount. À la sortie, une référence au groupe de tâches actuel est supprimée lorsque la dernière référence à chaque structure de signal est supprimée. Le groupe de tâches est détruit lorsque la dernière structure de signal qui y fait référence est libérée. Au moment de la sélection de la file d'attente, IFF une tâche n'a pas d'affectation de groupe de contrôle, son groupe automatique actuel est utilisé.

La fonctionnalité est activée au démarrage par défaut si CONFIG_SCHED_AUTOGROUP est sélectionné, mais peut être désactivée via l'option de démarrage noautogroup, et peut également être activée/désactivée à la volée [via /proc/sys/kernel/sched_autogroup_enabled :Écrit il le désactive pour les tâches nouvellement créées, en écrivant 1 l'active.]

Les principaux problèmes résolus par cela concernent les systèmes multicœurs et multiprocesseurs (SMP) qui connaissent des temps de réponse interactifs accrus lors de l'exécution d'autres tâches qui utilisent de nombreux threads dans ces tâches. Une explication simple est que l'on pourra toujours regarder une vidéo, lire des e-mails et effectuer d'autres activités de bureau typiques sans problèmes ni saccades lors de la compilation du noyau Linux ou d'un processus similaire tel que l'encodage vidéo. Cependant, il y a des objections à cette déclaration.