From: KOSAKI Motohiro Date: 2010-01-12T00:35:49+09:00 Subject: [ruby-dev:40037] Re: Linuxで bm_vm3_thread_mutex.rb が刺さってしまい実行が完了しない 2010年1月12日0:20 Yusuke ENDOH : > 遠藤です。 > > 2010年1月10日20:06 KOSAKI Motohiro : >> trunk + fedora12 >> の組み合わせにおいて、bm_vm3_thread_mutex.rbの実行が完了しません。調査の結果、本当にデッドロックしているのではなく、デッドロックチェックが過剰に呼ばれすぎているのが原因だと分かりました。 >> 要するに微妙なタイミングでレースに負けると毎回デッドロックチェックが走ってしまうのだが、ベンチが合計100万回mutex_lockするベンチなのでレースコンディションが、当初の予想ほどレアではなかったという事です。 >> >> 添付パッチのように、何回かレースに負けてから初めてデッドロックを疑うようにロジックを変更したところ100倍以上速くなるようです。 > > > IRC で話してしまいましたが、記録としてメールします。 > > > このパッチだと、guess_deadlock が常に 0 になるため、デッドロックの > チェックがされなくなってしまいます。 > このメールの最後のパッチなら正しく動きますが、高速化の度合いが大分 > 下がるようです。 > # パッチ前が 30 秒 〜 90 秒程度だったのが、25 秒 〜 35 秒程度？ > > しかし試しに rb_check_deadlock の呼び出しを消してみると、なぜか逆に > 遅くなるという現象がおきて、なんだか謎めいています。もっと調査が > 必要そうです。 > > けれど、bm_vm3_thread_mutex.rb の実行が終了しないくらい遅いのは困り > ますよね。どうしよう。 同じく記録のために書いています。ぼくのところだと trunk: 終わらん 今回遠藤さんが添付したパッチ： 140秒ぐらい 遠藤パッチ ＋ sched_compat_yield: 25秒ぐらい 遠藤パッチ ＋ naitive_yield()の実装を usleep(0)に変更： 30秒ぐらい last_threadを常に０にする：10秒 rb_check_deadlock の呼び出しを消す： 280秒ぐらい 同じ計算をするベンチをCで書き直して実行： 0.1秒ぐらい といったところです。 last_thread 0で10秒なところから、自分的にはデッドロックチェックありでも15秒以下に したいなーとか思って悩んでいるのですが、まだ良い案がありません。