User centric process scheduling

1. User centric process scheduling B4. Nguyen Tuan Duc

2. 全体の流れ • 背景と目的 • 提案手法 • 評価方法 • 今後の予定

3. 1.背景と目的 • 背景: • クラスタが多く使われるようになった • クラスタの資源を効率的に使いたい • クラスタでは、多くのプロセスが存在して、計算、通信、またはI/Oをしている。 • そのため、よいスケジューリング方法が必要である。

4. 背景と目的 • 目的: • クラスタの資源をなるべく利用でき、しかも、プロセスに対して、適当なタイミングで資源を与えられるスケジューリングアルゴリズムを作る • CPU utilization, wait timeのよいスケジューリング • ユーザの“満足さ”を最大にする。つまり、CPUを使いたいときはなるべく使わせ、応答速度を要求しているプロセスにも対応できるように • ユーザの目的に注目して、スケジューリングをする • ユーザが能動的にスケジューリング過程に参加させる

5. 2.提案手法 • プロセスに資源の使える時間の残りの値を持たせる。この値はOSによって割り当て、balanceと呼ぶ。 • Balanceが残ったらOSによって実行させる可能性がある(ready queueに入る)、balanceがなくなったら、wait queueに入る • プロセスが資源を使って、他のプロセスの邪魔をしたら、balanceを減らす • プロセスが資源を使うが、他のプロセスを邪魔しなければ、balanceは減少しない

6. 提案手法(2) • Interactive processの応答性を保証するために、balanceの減らし方をuserにより宣言できるようにする(どれぐらいbalanceを減らすかの情報をcostとする) • Balanceを大きく減らしたら、つまり、costが大きいなら、資源をすぐ使える • しかし、balanceは早くなくなる(interactive process は普通CPUをあまり使わない) • 資源を多く使いたいuserはbalanceを少しずつ減らす(costが小さいまたは0)。そのために、長い間資源を使うことができるが、優先度が低い

7. 提案手法(3) • クラスタでのアプリケーションは通常多くのプロセスを含む。 • 1つのプロセスがI/Oをしていて、他のプロセスが計算していることがある。 • そこで、プロセスごとに、costを宣言できると、プロセスごとの優先度がプロセスの目的に適切する。 • スケジューリングは分散的に行う(全体のアプリケーションではなく、プロセスごと) • 各プロセスがI/Oによって非同期であれば、問題なく、計算やI/Oが行われる • 同期ならば、計算するプロセスが待たなければならないが、そのために、balanceが大きくなるので、CPUが多く使える

8. 3.評価方法 • スケジューリングアルゴリズムを評価するためには、いくつかの指標が必要 • CPU utilization • Wait time • … • 提案した手法においては、更に、プロセスの“満足さ“を定義する: • S =

9. 評価方法(2) • S = • S(満足さ)の式のなかで、 • Alphaはcost/delta_balance, delta_balanceは更新際に、各プロセスに与えるbalance値である。 • CPUはそのプロセスのCPU使用率 • Waitは待ち時間

10. 評価方法(3) • 上で述べた指標を使い、提案したスケジューリングアルゴリズムと他のアルゴリズムと比較する • シミュレーションによる結果を使って評価する • 実際のシステムで実装して、評価する

11. 4.今後の予定 • 中間発表までの予定 • シミュレーションを使って、提案したスケジューリングアルゴリズムと他のアルゴリズムを評価する • シミュレータはSimGridまたはHyperSimを使う • Discrete event simulation • Abstraction of system as a set of dependant actions and events • 自分のスケジューリングのコードを埋め込むことができる

12. 今後の予定(2) • 最終的の予定 • 実際にアルゴリズムを実装して、評価する • Linux上で実装する予定