デスクトップコンテキストでのsystemdスケジューリング関連オプションの使用と理解
Systemdサービスファイルでは、次のスケジューリング関連オプションを設定できます（ systemd.execのマニュアルページから 、間違っている場合は修正してください）：
Nice実行されるプロセスのデフォルトのNiceレベル（スケジューリング優先度）を設定します。 -20（最高の優先順位）から19（最低の優先順位）の間の整数を取ります。詳細は setpriority（2） を参照してください。
おなじみのニースレベルです。最近のLinuxカーネルの「オートグループ」機能により、その効果はいくぶん「覆された」ようです。したがって、以下のオプションは、デスクトップエクスペリエンスでプロセスが適切に動作し続けるように設定したいものです。
CPUSchedulingPolicy実行されたプロセスのCPUスケジューリングポリシーを設定します。その他、バッチ、アイドル、FIFO、またはRRのいずれかを取ります。詳細は sched_setscheduler（2） を参照してください。
CPUSchedulingPriority実行されたプロセスのCPUスケジューリング優先順位を設定します。使用可能な優先度の範囲は、選択したCPUスケジューリングポリシーによって異なります（上記を参照）。リアルタイムスケジューリングポリシーの場合、1（最低の優先度）から99（最高の優先度）までの整数を使用できます。詳細は sched_setscheduler（2） を参照してください。
CPUSchedulingResetOnForkブール引数を取ります。 trueの場合、実行されたプロセスがフォークすると、CPUスケジューリングの優先順位とポリシーの昇格がリセットされるため、子プロセスにリークすることはできません。詳細は sched_setscheduler（2） を参照してください。デフォルトはfalseです。
最後のオプションを理解しました。最初の2つの説明から、スケジューリングポリシーを選択して、そのポリシーを優先することができると説明しました。どの種類のタスクのために何を選択すべきかは、私には完全には明らかではありません。たとえば、バックアップタスクに「アイドル」を選択しても安全ですか（重複排除のために比較的CPUに負荷がかかります）、それとも別の方が適していますか？
一般に、各ポリシーの概要と、その優先順位と特定の目的への適合性を理解することが、私が求めているものです。また、ニースレベルとの相互作用も重要です。
CPUスケジューリングの隣にIOスケジューリングがあります。これはioniceに対応すると思います（私が間違っている場合は修正してください）。
IOSchedulingClass実行されたプロセスのI/Oスケジューリングクラスを設定します。 0〜3の整数、またはnone、realtime、best-effort、idleのいずれかの文字列を取ります。詳細は ioprio_set（2） を参照してください。
IOSchedulingPriority実行されたプロセスのI/Oスケジューリング優先順位を設定します。 0（最高の優先順位）から7（最低の優先順位）までの整数を取ります。使用可能な優先度は、選択したI/Oスケジューリングクラスによって異なります（上記を参照）。詳細は ioprio_set（2） を参照してください。
ここでは、CPUスケジューリングと同じ構造が表示されます。同じ種類の情報も探しています。
すべての「スケジュール」オプションについて、言及されたマニュアルページは私にとって十分に明確ではありません。ほとんどは、技術的にやや傾けられたデスクトップユーザーの視点に物事を翻訳することにおいてです。
CPUScheduling {Policy | Priority}
リンクは、CPUSchedulingPriorityはfifoまたはrr（「リアルタイム」）タスクに対してのみ設定する必要があることを示しています。サービスにリアルタイムのスケジューリングを強制したくない場合。
CPUSchedulingPolicy=otherがデフォルトです。
batchとidleが残ります。それらの違いは、同時にCPUを消費するアイドル優先度のタスクが複数ある場合にのみ関係します。理論的には、batchの方がスループットが高くなります（レイテンシが長くなる代わりに）。しかし、それは大きな勝利ではないので、この場合はあまり関係ありません。
idleは、他にCPUが必要な場合、文字通り飢餓状態になります。シングルコアの古いUNIXシステムでは、CPU優先度は以前よりも重要度が低くなっています。私はNiceから始めてもっと幸せでしょう、例えばidleに頼る前のレベル10または14。次のセクションを参照してください。
ただし、ほとんどのデスクトップはほとんどの場合比較的アイドル状態です。また、バックグラウンドタスクをプリエンプトするCPUホグがある場合、ホグはいずれかのCPUのみを使用するのが一般的です。それを念頭に置いて、平均的なデスクトップまたはラップトップのコンテキストでidleを使用することは、それほど危険ではありません。 Atom/Celeron/ARM CPU定格 約15ワット以下 ）がない限り、もう少し注意してください。
ニースレベルはカーネルの「オートグループ」機能によって「破壊」されますか？
うん。
自動グループ化は少し奇妙です。 systemdの作者は、デスクトップであってもヒューリスティックを好まなかった。自動グループ化の無効化をテストする場合は、 sysctlkernel.sched_autogroup_enabledを0に設定できます。 sysctlを永続的な構成に設定して再起動し、すべての自動グループを削除することを確認してテストするのが最善だと思います。
その後、問題なくサービスのレベルをニースにできるはずです。少なくとも現在のバージョンのsystemd-次のセクションを参照してください。
例えば。 niceレベル10は、Linux CPUスケジューラで各スレッドの重みを約10％に減らします。ナイスレベル14は5％未満です。 （リンク： 完全な数式 ）
付録：nicedレベルはsystemd cgroupによって「破壊」されていますか？
現在のDefaultCPUAccounting=setting は、サービスごとにCPU制御を有効にせずに有効にできない限り、デフォルトでオフになります。だから大丈夫です。これは現在のドキュメントで確認できます：man systemd-system.conf
anyサービスがCPUAccounting/CPUWeight/StartupCPUWeight/CPUShares/StartupCPUSharesを設定すると、サービスごとのCPU制御も有効になることに注意してください。
次のブログの抜粋は古くなっています（まだオンラインです）。その後、デフォルトの動作が変更され、それに応じてリファレンスドキュメントが更新されました。
ニースのデフォルトとして、カーネルでcpuコントローラーが有効になっている場合、systemdは起動時に各サービスのcgroupを作成します。これ以上の設定がない場合、これにはすでに1つの素晴らしい効果があります。systemdシステムでは、構成されているプロセスの数に関係なく、すべてのシステムサービスに均等な量のCPUが割り当てられます。または言い換えると、Webサーバーでは、MySQLはApacheとほぼ同じ量のCPUを取得します。後者は1000のCGIスクリプトプロセスで構成されていますが、前者はいくつかのワーカータスクのみです。 （この動作はオフにすることができます。/etc/systemd/system.confのDefaultControllers =を参照してください。）
このデフォルトに加えて、サービスが取得するCPUシェアをCPUShares =設定で明示的に構成することが可能です。デフォルト値は1024です。この数を増やすと、変更されていない1024よりも多くのCPUがサービスに割り当てられます。減らすと、少なくなります。