アカウント名:
パスワード:
が実装されるっぽいです。
変な話ですけど、priority inheritanceはちゃんと実装するんでしょうね? 現状の実装を見たら目が点になったので...
あと、C言語上で同じ文であってもarchitectureによってlockが必要だったりいらなかったりすることがありますよね(i386はsparcなどほかのarchitectureに比べてhardwa
最近の2.4は追ってないけど、初期のではlockの種類を問わずpriority inheritanceが全く行われていなかったような。それから、Linux kernelで特に問題になっていないように見えるのは、まだmainstream kernelに対してdispatch delayを意識するapplicationが存在しないという背景があります。Solarisの時にはこれが初期から大問題になり(主にinterrupt threadとrealtime process、特に前者はシステム全体に響く)、結局priority inheritanceがpreemptive kernelとならんで強烈に効いたわけです。
memory barrierについては、最大の敵は「人間」で
聞き伝えですが、sparc64の場合はi386と違ってmemory accessをout-of-orderにやってしまうことが多いそうです(並列度を上げるためにはしょうがないけど)。したがって、memory barrierを置いたとしても、それまでに完了して欲しいwriteがmemory barrierにぶち当たるまでに確実に実行することが保証できません。当時の議論を読み返して気が付いたのですが、これはhardwareの問題であり、softwareではmemory barrierよりも高級なlock(せいぜいmutexで済むのが救いだが)を使うしかありません。
それから、このような問題はある構造体のたった1つのmemberを
386では問題なかった -> 字面上の命令の順序は問題なかった -> それでsparcで問題がおきたということはストア命令が他のプロセッサから違う順番で見えた ->* membar #Syncを入れると良い
*の部分ですが、問題が起きるのはC言語上では1つの文(たいていは式文)でありながら、assemblerに落とすと複数回のstoreを必要としてしまう場合です(2重以上の間接参照をdereferする場合など)。この場合はC言語ではそれ以上式を分割できないため、C言語のレベルでは解決できません(マクロなどは一切使えない)。
ではdereferenceを全てバラし
n重参照のdereference(n>2)は、例えば
p->p_pgrp->pg_jobc == 0
の左辺ですね。これはsignal処理の中で出てきた例(実際に問題になった)ですが、ほかにもprocess groupやsessionをprocessからたどる場合によく起こります。FreeBSDに関していえば、KSE(Kernel Scheduling Entity)のmergeにより、processももはや出発点ではなく、threadに貼りつくだけのものになってしまいました。ですから、
td->td_proc->p_pgrp->...
というdereferenceもぼちぼち出てきてます。まぁ、Cのレベルで複数の式文に分けることはできますが、実際にキーを打つ立場としてはそれをやると読みづらいし、あちこちいじらないといけないし、ローカル変数の初期化を忘れて...など、面倒なことの方が多いです(そんなことに時間を割く余裕はない)。
また、このような文を書いた場合、アドレス値のloadを複数回、しかも一般には不連続に(loadだけを連続実行することができない)繰り返すことになります。こうなるとmemory barrierだけではloadの間に入った別の命令を超えた保護ができません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
新機能 (スコア:5, 参考になる)
2.5で入るかもしれない機能のなかではプロセスごとにファイルシステムの名前空間を分ける機能(CLONE_NAMESPACE?)と入出力のより一般的な扱い(マルチキーボード、マルチディスプレー、マウスによる複数端末としての利用)に期待しています。
あとは
が実装されるっぽいです。
Re:新機能 (スコア:5, 興味深い)
変な話ですけど、priority inheritanceはちゃんと実装するんでしょうね? 現状の実装を見たら目が点になったので...
あと、C言語上で同じ文であってもarchitectureによってlockが必要だったりいらなかったりすることがありますよね(i386はsparcなどほかのarchitectureに比べてhardwa
Re:新機能 (スコア:3, 興味深い)
現時点でLinuxのパフォーマンスの分析した記事や論文を見る限り、そのへんが実際に問題になっているというデータはない(僕の知る限り）ので、2.5ではやらない or 後回しじゃないでしょうか。
Re:新機能 (スコア:3, 参考になる)
最近の2.4は追ってないけど、初期のではlockの種類を問わずpriority inheritanceが全く行われていなかったような。それから、Linux kernelで特に問題になっていないように見えるのは、まだmainstream kernelに対してdispatch delayを意識するapplicationが存在しないという背景があります。Solarisの時にはこれが初期から大問題になり(主にinterrupt threadとrealtime process、特に前者はシステム全体に響く)、結局priority inheritanceがpreemptive kernelとならんで強烈に効いたわけです。
memory barrierについては、最大の敵は「人間」で
Re:新機能 (スコア:1)
これについては強く同意します。んで
>> 実際、i386では平気だと思っていたものがsparc64ではうまく動かず、lockのかけなおしをする羽目になった経験があります。
これですが(gccですが)sparcの方に__asm__("membar #Sync":::"memory")、86の方に__asm__("
Re:新機能 (スコア:3, 興味深い)
聞き伝えですが、sparc64の場合はi386と違ってmemory accessをout-of-orderにやってしまうことが多いそうです(並列度を上げるためにはしょうがないけど)。したがって、memory barrierを置いたとしても、それまでに完了して欲しいwriteがmemory barrierにぶち当たるまでに確実に実行することが保証できません。当時の議論を読み返して気が付いたのですが、これはhardwareの問題であり、softwareではmemory barrierよりも高級なlock(せいぜいmutexで済むのが救いだが)を使うしかありません。
それから、このような問題はある構造体のたった1つのmemberを
Re:新機能 (スコア:1)
i386では問題なかった -> 字面上の命令の順序は問題なかった -> それでsparcで問題がおきたということはストア命令が他のプロセッサから違う順番で見えた -> me
Re:新機能 (スコア:2)
*の部分ですが、問題が起きるのはC言語上では1つの文(たいていは式文)でありながら、assemblerに落とすと複数回のstoreを必要としてしまう場合です(2重以上の間接参照をdereferする場合など)。この場合はC言語ではそれ以上式を分割できないため、C言語のレベルでは解決できません(マクロなどは一切使えない)。
ではdereferenceを全てバラし
Re:新機能 (スコア:1)
>>C言語上では1つの文(たいていは式文)でありながら、assemblerに落とすと複数回のstoreを必要としてしまう場合です(2重以上の間接参照をdereferする場合など)。この場合はC言語ではそれ以上式を分割できないため
の例を示していただけないでしょうか
Re:新機能 (スコア:2)
n重参照のdereference(n>2)は、例えば
の左辺ですね。これはsignal処理の中で出てきた例(実際に問題になった)ですが、ほかにもprocess groupやsessionをprocessからたどる場合によく起こります。FreeBSDに関していえば、KSE(Kernel Scheduling Entity)のmergeにより、processももはや出発点ではなく、threadに貼りつくだけのものになってしまいました。ですから、
というdereferenceもぼちぼち出てきてます。まぁ、Cのレベルで複数の式文に分けることはできますが、実際にキーを打つ立場としてはそれをやると読みづらいし、あちこちいじらないといけないし、ローカル変数の初期化を忘れて...など、面倒なことの方が多いです(そんなことに時間を割く余裕はない)。
また、このような文を書いた場合、アドレス値のloadを複数回、しかも一般には不連続に(loadだけを連続実行することができない)繰り返すことになります。こうなるとmemory barrierだけではloadの間に入った別の命令を超えた保護ができません。
Re:新機能 (スコア:1)
>>C言語上では1つの文(たいていは式文)でありながら、assemblerに落とすと複数回のstoreを必要としてしまう場合です(2重以上の間接参照をdereferする場合など)。この場合はC言語ではそれ以上式を分割できないため
に対するもので、この場合storeはやってないように見えます。
それから
>>実際、i386では平気だと思っていたものがsparc64ではうまく動かず、lockのかけなおしをする羽目になった
と書かれていますが、このコードはi386ではロックなしで問題ないのでしょうか？