パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

デスクトップを加速する新スケジューラー」記事へのコメント

    • どういう仕組みなのか詳細不明なのですが、2.4.xまでのスケジューラは純粋なTSSのため、マルチメディア系の処理が駄目駄目なんですよねぇ。
      2.5.2+で、MontaVistaの0(1)スケジューラが取り込まれていますが、これも謳い文句の割にはマルチメディア系の処理はイマイチなようで。
      きめ細かいスレッド処理が可能なスケジューラなら、通常のシングルCPUでのスレッド処理でも、効果はあるでしょうね。
      親コメント
      • O(1) スケジューラの肝は、スケジュールするべきプロセスの選択にかかるオーバーヘッドが一定(プロセス/スレッドが増えても増加しない、Orderが定数(1)である)ことです。

        一方、マルチメディア系で求められるのは、応答時間が保証されるリアルタイム性ですから、スケジューリングの戦略が異なります(両立は容易ではない)。

        古い実装だとプロセス増加でスケジューリングのオーバーヘッドが増え、特にマルチプロセッサのとき顕著だ、ということです。オーバーヘッド増加の原因としてスケジューリングでアクセスするプロセス情報がメモリの広範囲に及ぶ(キャッシュミスを起こしやすい)と言うのがあり、この問題を解決すると、マルチプロセッサや HT での性能はもちろん、従来のプロセッサでも性能が上がります。

        前から BSD に比べて Linux のスケジューリング(高負荷時の応答性、バックグラウンドでコンパイルしてるときシェルの応答性とか)が悪いなぁ、と思っていたんですが、まんざら気のせいでもなかったようです。高負荷時のパフォーマンスは BSD の方が良いというのはスケジューラの出来の差でしょう(TCP スタックの出来もあるけど)。 まあ、高負荷な状況で使う人じゃないとあまり違いはないんでしょうけどね。

        --
        親コメント
        • by Anonymous Coward on 2003年03月16日 13時02分 (#280070)
          Linuxの高負荷での問題の大きな原因はスケジューラよりも
          async mountにあると指摘しておきます。

          dirtyなメタデータの書き込みにはかなりのメモリと時間が 必要なのですが、async mountの場合は高負荷かつ メモリが足りない状況でこの処理が発生することが多く、 著しく性能が低下してしまいます。

          対策は行われつつあるので、近いうちに改善されることでしょう。
          親コメント
        • 古い実装だとプロセス増加でスケジューリングのオーバーヘッドが増え、特にマルチプロセッサのとき顕著だ、ということです。オーバーヘッド増加の原因としてスケジューリングでアクセスするプロセス情報がメモリの広範囲に及ぶ(キャッシュミスを起こしやすい)と言うのがあり、この問題を解決すると、マルチプロセッサや HT での性能はもちろん、従来のプロセッサでも性能が上がります。
          2.4.Xのスケジューラでキャッシュミスが多発するのは"メモリの広範囲"にアクセスするからではなくて、task_struct が8KBでアラインしているためにキャッシュコンフリクトをおこすからです。メモリプロファイリングをすると一発でわかります。
          http://hardmeter.osdn.jp/prosym.pdf あたりを参照してください。
          親コメント
      • >>MontaVistaの0(1)
        0(1)じゃなくてO(1)です。
        MontaVistaではなく、Ingo Molnarです。

ソースを見ろ -- ある4桁UID

処理中...