niceレベルが無視されるのはなぜですか? (異なるログインセッション間 - 同じセッションで開始することをお勧めします。)

niceレベルが無視されるのはなぜですか? (異なるログインセッション間 - 同じセッションで開始することをお勧めします。)

異なる良好なレベルで 2 つの CPU 消費プロセスを開始する場合、たとえば

プロセス1:

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

プロセス2:

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

:true(またはの出力からプロセスを区別するために、およびの順序を変更しました)、pstop

良いレベルは無視され、両方とも同じ量のCPUを使用しているようです。

topの出力

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

(もちろん、%CPUサンプルごとにその値は少しずつ異なりますが、平均的には同じです。)

topこれは、両方のプロセスが異なるNice値で実行されていますが、まだ同じCPU時間を取得しているようです。

どちらのコマンドも、異なる端末(両方のログインシェル)で同じユーザーによって実行されました。

同じ端末で実行すると、期待どおりに動作します。より良いプロセスはあまり良くないプロセスに譲歩します。

なぜですか?マシン全体の全体的な状況をどのようにうまく実行できますか?

しばらく前まで、そのマシンの状況は変わり、良い価値は尊重されているようでした。

シングルプロセッサ/シングルコアマシンです。

詳細は:

  • カーネル:バージョン4.4.5(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:
    

答え1

ああ、各ユーザーが独自のcgroupを持つsystemd-logind機能ではありません。私はここに関連する変更がより古いと思います。混乱するほど似ています。 (私は「プロセスグループの公正なスケジューリング」を検索し、それが私が実際に理解していないUnixの「プロセスグループ」に基づいている可能性があると思いました。)ウィキペディア:

Linuxカーネルは2010年11月に2.6.38カーネル用のCFSパッチを受け取り、スケジューラがデスクトップやワークステーションでの使用に適しています。

ジョブが__proc_set_tty()を呼び出すと、デフォルトグループへのプロセス全体の参照が削除され、新しいワークグループが作成され、プロセスが新しいワークグループに移動されます。その後、子供たちはワークグループを継承し、その数を再び増やします。終了時に各シグナル構造への最後の参照が削除されると、現在のワークグループへの参照も削除されます。ワークグループを参照する最後のシグナル構造が解放されると、ワークグループは削除されます。キュー選択を実行するときにジョブにcgroupが割り当てられていない場合、現在の自動グループが使用されます。

CONFIG_SCHED_AUTOGROUPを選択した場合、この機能は起動時にデフォルトで有効になりますが、起動オプションnoautogroupを介して無効にしたり、動的にオンまたはオフにしたりできます。[via /proc/sys/kernel/sched_autogroup_enabled0そこに書くと新しく作成されたジョブは無効になり、そこに書き込むと1有効になります。 ]

これによって解決される主な問題は、マルチコアシステムとマルチCPU(SMP)システムがこれらのタスクで多くのスレッドを使用する他のタスクを実行すると、対話型応答時間が増加することです。簡単な説明は、Linuxカーネルをコンパイルしたり、ビデオや同様のプロセスをエンコードしている間に、欠陥や不安定なしでビデオを見たり、電子メールを読んだり、他の一般的なデスクトップアクティビティを実行したりできることです。しかし、この発言に対する反論もある。

関連情報