Linuxプロセススケジューラは、O(n)O(n)であるかどうかに関係なく、一般的なスケジューラです。O (n )、O(1)O(1)O (1 )、またはCFSは、統一されたインデックスに基づいてすべてのプロセスを処理します。言い換えれば、プロセスはそれ自体で譲歩することさえできません。
プロセスの優先順位が決定されている限り、スケジューリングアルゴリズムが何であっても、プロセスのステータスが変わることはありません。次の戦略を達成できれば素晴らしいと思います。
- システムにさらに多くのプロセスがある場合、それはスピードアップして譲歩します。
- システム内のプロセスが少ない場合、プリエンプションが加速されます。
- 労働者が来たとき、彼らは屈服した。
- マネージャーが来ると、彼は先制します。
- …
特定のシステムで実行されているプロセスAについて考えてみます。このプロセスは、CPUの最大40%しか使用できません。現時点では、実行する他のプロセスがある場合、別のプロセスAが来ると、これらのプロセスはCPUの残りの60%を自然に共有します。 ?明らかに、2つのプロセスAのCPU時間は削減されます。
2つのプロセスAが引き続きCPUの40%を使用し、他のプロセスがCPUの残りの20%を共有することを保証できますか?それは難しい!
グループを構成できると言うかもしれませんが、静的な構成プロセスが必要であり、動的に適応させるのは困難です。
言い換えれば、Linuxスケジューラーは弾力性がありません!
次のコードは、単純で柔軟なスケジューリングを示しています。
#!/usr/local/bin/stap -g
probe kernel.function("__enqueue_entity")
{
task = _task_of($se)
pid = @cast(task, "struct task_struct")->pid
if ($1 == pid) {
_nr = $cfs_rq->nr_running
t = $se->vruntime;
$se->vruntime = t + 3000000*(_nr - 1)
}
}
これは、指定されたプロセスがシステムの負荷量に応じて降伏することを意味します。
- システム負荷が高いほど、指定されたプロセスが占めるCPU時間の割合は低くなります。
- システム負荷が低いほど、指定されたプロセスが占めるCPU時間の割合が高くなります。
来て、効果を見てください:
あなたは見ることができます:
- ループが1つしかない場合は、CPUの100%を占有します。
- ループを再生成すると、CPUが最初のループでほぼ均等に分割されます。
- 実行中のループが増えると、最初のループのCPUシェアは徐々に減少します。
- これは同じルートであり、最初のループのみが柔軟です。
まあ、効果は大丈夫ですが、十分に滑らかではありません。二次曲線、または三次曲線を試してみますか?
$se->vruntime = t + 200*(_nr - 1)*_nr*_nr
// or
// $se->vruntime = t + 20000*(_nr - 1)*_nr
200はどこから来たのですか?パラメータをうまく調整する必要があります。
さらに、ここでの私の柔軟な戦略は単一すぎます。実際、十分に複雑になるように設計できます。たとえば、特定のプロセスの特定の戦略は、単純な二重傾斜の直線セグメントであっても、私のものよりも優れています。強制されたふりをしないでください。いう。
誰かが修正するコードを見つける方法を尋ねました。Linuxカーネルの実装原則に精通している限り、それは難しいことではありません。職人にとって、アルキメデス、ルバン、パオディン、ファンダオポはステータスに値します。ユークリッド以上、デスカルテス。
浙江文州の革靴は濡れているので、雨でも太りません!