Document

感性を考慮した
ジョブスケジューリング
東京工業大学情報理工学研究科
数理・計算科学専攻千葉研究室
栗田亮
1
音楽聴きながら仕事してます
► ・・・しながら族
増加中
 現在マシンは高性能
 音楽を聴きながら
仕事する人は多い
►研究室でも多く存在
►DVD見ながら仕事
をするツワモノも
2
仕事が優先(当然!)なのですが・・・
► ユーザの希望:
仕事が第一だけど音楽・映像も
 実装, 論文作成などの仕事 → すばやく処理
 音楽,DVD → 仕事の邪魔にならなければよい
► マシンにその希望は反映されない
 仕事の処理を優先させる
►音楽・映像が途切れて不快
 音楽・映像再生を優先させる
►仕事の処理が遅れる
3
感性を考慮したQoS処理
► 仕事があくまで優先!
 マシンには仕事の処理を優先させる
► 音楽・映像には感性を考慮したQoS処理を行う
 途切れなどによるユーザへの不快感を抑制
例) 音楽のフェードアウト
►途切れを防ぐには止めるしかない場合もある
►その際にフェードアウトさせることでユーザへの不快感を
抑えることが可能
4
Tanma
► 重要性の低い音楽再生処理に対しQoS処理を
行うシステム
 ユーザに不快感を与える前に音楽を制御
►音楽再生処理の進捗情報を利用するスケジューリング
 音楽の停止・再開に伴うユーザへの不快感を抑制
►音量の自動調整
►タイムマシン再生
 Linuxカーネル上に実装
►アプリケーションを書き換える必要なし
5
Tanmaのスケジューリング
► 重要性の高い処理が阻害されているときだけ
音楽を制御
 音楽再生処理による阻害
►CPUなどの資源の競合（奪い合い）により処理が遅れる
 状況に応じて資源割り当てを変更
→ 音楽を制御
►阻害されていない場合 → 音楽をそのまま続行
►阻害されている場合
 従来のCPUスケジューリングでは困難
►CPU以外の資源の競合を探知できない
6
Progress-based regulation
[J.R.Doucer 99]
► 進捗情報を用いるスケジューリング手法
 プロセスの進捗をもとに資源競合を探知
►重要性の低いプロセスの進捗に注目
= 重要性の高いプロセスとの資源競合
→ 重要性の高いプロセスの処理を阻害
►資源によらずに競合の探知が可能
►進捗が悪化
 資源競合を解消するためにプロセスを制御
►重要性の低いプロセスを一定時間停止
→ 重要性の高いプロセスが阻害されなくなる
7
Tanmaによる進捗状況判定
► Progress-based
regulationを音楽処理に適用
 進捗値＝カーネルがバッファリングしているサウンド
データの量
►通常時：
アプリケーションからのデータが十分
►負荷時：アプリケーションの遅延によりデータが不足
 閾値と比較して進捗状況を判断
►閾値
= 過去の進捗値の平均値より計算
デバイス
カーネル
アプリケーション
バッファ
8
Tanmaによるプロセス制御
► 進捗の悪化に伴い音楽再生処理を制御
 音が途切れる前に音楽を一定時間停止
►停止時間:
3秒
 停止後に一時的に処理を再開し、再停止 or 続行
►重要性の高い処理の終了後、遅くとも3秒後に再開
→ ユーザが許容できる待ち時間
進捗悪化
音楽再生
重要性の
高い処理
一時的に再開 &
進捗チェック
進捗良好
3秒停止
9
開始
終了
音量の自動調整
► 停止・再開時に音量変更
 ユーザに不快感を与えないよう停止・再開
► 停止後の進捗状況チェックは音量ゼロ
 一時的な音楽再生をユーザに聞こえさせない
音
量
進捗悪化
フェードアウト
進捗良好
フェードイン
0
音楽再生
重要性の
高い処理
10
タイムマシン再生
► フェードアウト前の部分から再生を再開
 フェードアウト中の音楽を録音し、再開時に再生
►カーネル内の専用バッファにデータを保持
 ユーザが音楽の一部を聴けないという事態を防ぐ
 一時的な再開時に再生したデータも改めて再生
音
量
フェードアウト
フェードイン
0
音楽再生
音楽ストリーム
1 2 3 4 5
6
7
3 4 5 6 7 8 9…
11
動作検証
► 既存の音楽プレイヤーに対し動作を確認
 realplayer, xmms, mpg123など
► デモ
 TanmaによるBGMの制御とQoS処理を示す
12
実験１： Tanmaによる資源競合回避
► 資源競合による重要な処理の遅延を検証
 BGM起動上で重要な処理（π計算）の処理時間を測
定
 Tanma未使用（3通り）とTanma使用で比較
 実験環境
►音楽プレイヤー：realplayer
(π計算アプリケーション)
►CPU: Pentium Ⅲ 733MHz, メモリ: 512MBの計算機
►重要な処理:pi_fftc
13
実験１の結果・考察
pi_fftc のみ
pi_fftc + realplayer
pi_fftc の CPU優先度↑
Tanma使用
処理時間
711秒
821秒(+15%)
777秒(+9%)
731秒(+2.8%)
音楽のQoS
ー
○
×
△
► 考察
 Tanmaが音楽プロセスを制御することで、π計算を
遅らすことなく処理できる
14
実験２: Tanmaのオーバーヘッド
► Tanmaの処理により遅延が生じているかを検証
 π計算実行中の音楽プレイヤーの進捗値を測定
= カーネルがバッファリングしているデータ量
= データ送信を行うアプリケーションの速度
►バッファサイズ: 131,072 byte
►進捗値
 通常のシステム、Tanma、Tanma(音量調整を実行
中)で比較
 実験１と実験環境は同じ
15
バッファリング
しているデータ量
（=進捗の速度）
(byte)
実験２の結果・考察
130,000
120,000
110,000
100,000
90,000
80,000
通常システム
Tanma
Tanma(音量変更中)
► 考察
 Tanmaの処理による負荷はほとんどない
16
進捗情報を用いる別の手法
►MS Manners [J.R.Doucer 99]
 デフラグなどのユーザに見えない処理を制御
 重要性の低い処理のQoSは無視
► QoS
adaptation & real-rate scheduling
[A.Goel 01]
 マルチメディア処理 = 重要性の高い処理
► Tanma
 マルチメディア処理 = 重要性の低い処理
 重要性の低い処理のためのQoS処理をプラス
►ユーザの感性を考慮
17
まとめ
► 重要性の低いマルチメディア処理のためのQoS
の提案
 マルチメディア処理から資源を奪う際にユーザの感
性を考慮したQoS処理が必要
►ユーザに与える不快感を抑制する
► Tanmaを開発
 ユーザの感性を考えて音楽を停止・再開
 Progress-based regulationをマルチメディア処理に
適用
18
今後の課題
► 動画再生処理に対するQoS処理
 フェードアウトなどの処理はカーネルレベルでは困難
 動画中の音楽には可能
► ネットワーク上の音楽の再生処理
 サウンドバッファの監視では進捗状況把握は困難
►アプリケーションによるバッファリングで遅延
 ネットワーク流量を監視する方法が考えられる
► より汎用的な機能が必要
19

Download Report