seqcountが preempt_disableしてない件について というエントリで、seqcountってプリエンプションをなーんも考えてないんだけど、呼び出し側のi_size_write() もなーんも考えてないように見える。これって大丈夫なの?
という疑問を問いかけたら、ひらさんから、i_semを忘れてる。とご指摘をいただいた。
なるほど。おっしゃる通りである。
とゆーわけで安心しつつも、いつおうkernel2.6.17で確認をいれてみる。
・・・・
・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・
i_sem がそもそも消えていますがなにか?
いや、かわりに i_mutex が追加されていて、
セマフォじゃなくてミューテックスで保護してるので、排他自体はしてるだが、ミューテックスって誰かとバッティングしないかぎり
atomic_xchg();
smp_mb();
の2行で抜けてくるので、プリエンプションはdisableされてないっぽげ。
なので、やっぱりワーストケースでは、i_size_write中にプリエンプションされてi_size_readがえらい待たされるケースがありそうな気がするでゴワスよ。
今のところの結論。
前回の指摘の1は、やっぱり疑わしい。
2と3は脳みそが腐っていたっぽげ。
しかし、つくづく記事にミスが多いブログだこと(^^ゞ

細かい事は気にしない! ランキング!
という疑問を問いかけたら、ひらさんから、i_semを忘れてる。とご指摘をいただいた。
なるほど。おっしゃる通りである。
とゆーわけで安心しつつも、いつおうkernel2.6.17で確認をいれてみる。
・・・・
・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・
i_sem がそもそも消えていますがなにか?
いや、かわりに i_mutex が追加されていて、
セマフォじゃなくてミューテックスで保護してるので、排他自体はしてるだが、ミューテックスって誰かとバッティングしないかぎり
atomic_xchg();
smp_mb();
の2行で抜けてくるので、プリエンプションはdisableされてないっぽげ。
なので、やっぱりワーストケースでは、i_size_write中にプリエンプションされてi_size_readがえらい待たされるケースがありそうな気がするでゴワスよ。
今のところの結論。
前回の指摘の1は、やっぱり疑わしい。
2と3は脳みそが腐っていたっぽげ。
しかし、つくづく記事にミスが多いブログだこと(^^ゞ

細かい事は気にしない! ランキング!
コメント
コメント一覧 (3)
>なので、やっぱりワーストケースでは、i_size_write中にプリエンプションされてi_size_readがえらい待たされるケースがありそうな気がするでゴワスよ。
同意です。
運用的に考えるとCONFIG_SMP&CONFIG_PREEMPTは”今まで”はあまり考えられないケースです。MPは通常サーバなのでスループット重視でCONFIG_PREEMPT_NONEに設定されます。なのでもしかすると、このコードを書いた人はそういった想定をしていない可能性はあります。
inode->i_sizeの扱いに関して、個人的にセマフォやmutexを使う必要があったのか疑問を持っています。排他区間が極めて小さいことを考えるとスピンロックを使うべきではないかと。スリープさせるよりビジーウェイトで回した方が排他コストが低いように思います。
そんな運用しませんから。と。
それは納得できる意見ですね。
スピンロックの件はすいません。オイラI/O系あんまり強くないんで判断できません。
i_sizeに限ればその通りだけど、他のメンバの更新でスピンじゃまずいケースってないのかなぁ・・・・
まずいですねぇ(笑)
なので撤回(^^;)