Když spustím dva procesy požírající CPU s různou úrovní nice, např.
Proces 1:
nice -19 sh -c 'while true; do :; done'
Proces 2:
sh -c 'while :; do true; done'
(Změnil jsem pořadí : a true stačí rozlišit procesy ve výstupech ps nebo top ),
zdá se, že úroveň nice je ignorována a obě využívají stejné množství CPU.
Výstup top je jako
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
[...]
(samozřejmě %CPU -hodnoty se mírně liší vzorek od vzorku, ale v průměru se zdají být stejné).
top ukazuje, že oba procesy běží s různými pěknými hodnotami, ale přesto se zdá, že zabírají stejné množství času CPU.
Oba příkazy byly spuštěny stejným uživatelem z různých terminálů (oba jsou přihlašovací shelly).
Pokud jsou spouštěny ze stejného terminálu, chovají se podle očekávání:Lepší proces uvolňuje místo tomu nepříliš pěknému.
Jaký je důvod? Jak udělat hezkou práci globálně na celém stroji?
Na tom samém stroji to bylo před časem jiné, kde se zdálo, že se ctí pěkné hodnoty.
Jedná se o jeden procesor/jednojádrový stroj.
Pro informaci:
- Jádro:Verze 4.4.5 (skladové jádro Arch Linuxu);
uname -r:4.4.5-1-ARCH, -
/proc/cpuinfoje: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:
Přijatá odpověď:
Aha, není to funkce systemd-logind, kde každý uživatel získá svou vlastní cgroup. Myslím, že změna, která je zde zodpovědná, je starší; jsou jen zmateně podobné. (Hledal jsem „process group fair scheduling“ a myslel jsem si, že by to mohlo být něco založeného na „process group“ unixu, kterému nikdy moc nerozumím). Wikipedie:
Linuxové jádro obdrželo opravu pro CFS v listopadu 2010 pro jádro 2.6.38, díky kterému je plánovač spravedlivější pro použití na desktopech a pracovních stanicích.
Když úloha volá __proc_set_tty(), je zrušen odkaz na výchozí skupinu celého procesu, je vytvořena nová skupina úloh a proces je přesunut do nové skupiny úloh. Děti poté zdědí tuto skupinu úkolů a zvyšují její počet. Při ukončení je odkaz na aktuální skupinu úloh zrušen, když je vypuštěn poslední odkaz na každou strukturu signálu. Skupina úkolů je zničena, když je uvolněna poslední struktura signálu, která na ni odkazuje. V době výběru runqueue IFF úloha nemá přiřazení cgroup, použije se její aktuální autogroup.
Funkce je ve výchozím nastavení povolena při spouštění, pokud je vybrána možnost CONFIG_SCHED_AUTOGROUP, ale lze ji deaktivovat pomocí možnosti spouštění noautogroup a lze ji také zapnout/vypnout za chodu [přes
/proc/sys/kernel/sched_autogroup_enabled:Zápistam jej deaktivuje pro nově vytvořené úlohy zápisem1umožňuje.]Primární problémy, které to řeší, se týkají vícejádrových systémů a systémů s více procesory (SMP), které zažívají zvýšenou dobu interaktivní odezvy při provádění jiných úloh, které v těchto úlohách využívají mnoho vláken. Jednoduchým vysvětlením je, že při kompilaci linuxového jádra nebo podobném procesu, jako je kódování videa, budete moci stále sledovat video, číst e-maily a provádět další typické činnosti na ploše bez závad nebo sekání. Proti tomuto tvrzení však existují námitky.