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

開発版Linuxカーネル2.5.0 == 2.4.15登場」記事へのコメント

  • 新機能 (スコア:5, 参考になる)

    2.4.15でO_DIRECTが復活してて、謎の/dev/rawを使わなくてもrawデバイスが使えるようになってるみたいです(ext2とblock deviceに対応)。
    2.5で入るかもしれない機能のなかではプロセスごとにファイルシステムの名前空間を分ける機能(CLONE_NAMESPACE?)と入出力のより一般的な扱い(マルチキーボード、マルチディスプレー、マウスによる複数端末としての利用)に期待しています。
    あとは
    • ファイルのマルチストリーム(ntfsとかmacのfsにあるやつ)
    • posix acl(or 互換するもの)
    • 非同期I/O

    が実装されるっぽいです。

    • 変な話ですけど、priority inheritanceはちゃんと実装するんでしょうね? 現状の実装を見たら目が点になったので...

      あと、C言語上で同じ文であってもarchitectureによってlockが必要だったりいらなかったりすることがありますよね(i386はsparcなどほかのarchitectureに比べてhardwa

      • priority inheritanceがないっていうのは、spinlockの話ですよね?
        現時点でLinuxのパフォーマンスの分析した記事や論文を見る限り、そのへんが実際に問題になっているというデータはない(僕の知る限り)ので、2.5ではやらない or 後回しじゃないでしょうか。
        • 最近の2.4は追ってないけど、初期のではlockの種類を問わずpriority inheritanceが全く行われていなかったような。それから、Linux kernelで特に問題になっていないように見えるのは、まだmainstream kernelに対してdispatch delayを意識するapplicationが存在しないという背景があります。Solarisの時にはこれが初期から大問題になり(主にinterrupt threadとrealtime process、特に前者はシステム全体に響く)、結局priority inheritanceがpreemptive kernelとならんで強烈に効いたわけです。

          memory barrierについては、最大の敵は「人間」で

          • >> memory barrierについては、最大の敵は「人間」です。
            これについては強く同意します。んで
            >> 実際、i386では平気だと思っていたものがsparc64ではうまく動かず、lockのかけなおしをする羽目になった経験があります。
            これですが(gccですが)sparcの方に__asm__("membar #Sync":::"memory")、86の方に__asm__("
            • 聞き伝えですが、sparc64の場合はi386と違ってmemory accessをout-of-orderにやってしまうことが多いそうです(並列度を上げるためにはしょうがないけど)。したがって、memory barrierを置いたとしても、それまでに完了して欲しいwriteがmemory barrierにぶち当たるまでに確実に実行することが保証できません。当時の議論を読み返して気が付いたのですが、これはhardwareの問題であり、softwareではmemory barrierよりも高級なlock(せいぜいmutexで済むのが救いだが)を使うしかありません。

              それから、このような問題はある構造体のたった1つのmemberを

              • /.らしからぬテクニカルな議論なので、もうちょっとお付き合いいただけるとありがたいです。i386ではよくてsparc64ではロックまでしないといけなかったというのがわからないので、教えてください。
                i386では問題なかった -> 字面上の命令の順序は問題なかった -> それでsparcで問題がおきたということはストア命令が他のプロセッサから違う順番で見えた -> me
              • 386では問題なかった -> 字面上の命令の順序は問題なかった -> それでsparcで問題がおきたということはストア命令が他のプロセッサから違う順番で見えた ->* membar #Syncを入れると良い

                *の部分ですが、問題が起きるのはC言語上では1つの文(たいていは式文)でありながら、assemblerに落とすと複数回のstoreを必要としてしまう場合です(2重以上の間接参照をdereferする場合など)。この場合はC言語ではそれ以上式を分割できないため、C言語のレベルでは解決できません(マクロなどは一切使えない)。

                ではdereferenceを全てバラし

              • 最初にお断りしておきますが 私は kernel hacker ではないので、 このスレッドの同期の話を OS 以外の場所に広げた一般的な話として 解釈しています。

                brake-handle さんのおしゃる通りなのですが 「問題が起きるのはC言語上では1つの文(たいていは式文)でありながら、assemblerに落とすと複数回のstoreを必要としてしまう場合」 以上に、 C コンパイラの最適化の掛かり方が 問題になることが多いと思います。

                td->td_proc->p_pgrp->...

                は2回の load に変換されるわけですが、 最適化によってこの2つの load 命令の距離が

                --
                コンタミは発見の母
              • by tabatee (1637) on 2001年11月25日 15時11分 (#41120) 日記
                いちおう、その辺のことは知ってるつもりなんですが
                >>i386では平気だと思っていたものがsparc64ではうまく動かず、lockのかけなおしをする羽目になった経験があります。
                なんてことがありうるのだろうかと興味があったのでダラダラと議論を長引かせてしまいました。上記の指摘された問題であればi386の方でもマズイですよね?doubleとか64bit整数だと逆にsparc64では大丈夫ってことになりそうですし。
                親コメント

犯人はmoriwaka -- Anonymous Coward

処理中...