make sched_yield more agressive-CELLプロセッサ

linux kernel v2.6.23 から Completely Fair Scheduler (CFS) という新しいスケジューラが導入されましたが、これに伴い sched_yield() の挙動が大幅に変更されています。簡単に言うと、スレッドが sched_yield() を発行すると、次回のスレッド実行が以前のバージョンの kernel と較べると遅くなります。で、以前と同じ挙動にするためには以下のように kernel を設定すれば良いようです。

echo 1 > /proc/sys/kernel/sched_compat_yield

また、関連する commit は以下になります。

sched: add /proc/sys/kernel/sched_compat_yield

x264 for cell でも sched_yield() は多用しており、v2.6.21 から v2.6.23 にバージョンを上げた時に速度が低下したため、しばらくは v2.6.21 を使用していました。が、v2.6.21 は正常にリブート出来ない上に nfs の使用に難があるため、やっぱり v2.6.23 を使用しようということで kernel source を調べて判明しています。で、原因が sched_yield() にあると分かって念のため google してみるとすでに以下の記事があってガックリなわけですが、、

x264 for cell ではどう sched_yield() を使用している？

x264 for cell では PPE <-> SPE 間通信が多対一となっているため、PPE->SPE は SPU シグナルが使用出来ますが、SPE->PPE は、複数の PPE スレッドが一つの SPE スレッドに対して待ち状態になっているため、SPU アウトバウンド(割り込み)メールボックスを使用しようとすると、pthread の cond や mutex を組み合わせて複雑な通信方式を実現しなければならないからです。この代わりとして、 SPE が処理終了時にメモリを変更するので、このメモリを PPE で監視して、未終了なら sched_yield() するようにしています。 (つまり PPE<->SPE 間で mutex, cond 等を実現する場合と同じことをしています) 速度や実現性を考えると kernel のドライバを作成するというのも考えていますが、、

他の Cell 用ソフトでは？

fixstars 社で公開されている CTK: Cell ToolKit Library でも PPE-SPE 間で使用可能な mutex, cond, queue 等を実現するために使用しています。(source としては以下の辺り)

./ctk/sync/ppu/ctk_mutex-impl.h
./ctk/sync/ppu/ctk_sem-impl.h
./ctk/sync/ppu/ctk_cond-impl.h
./ctk/sync/ppu/ctk_genericq-impl.h
./ctk/sync/ppu/ctk_barrier-impl.h
./ctk/sync/ppu/ctk_queue-impl.h

また、SPE 側では sched_yield() に該当する箇所で random delay させており、スラッシングしないように工夫されています。

逆に、Cell SDK 内で提供されている libsync の mutex, cond では sched_yield() は使用せず、スピンロックする(実行権を放棄しない)ようです。

sched_yield() は使うべき？使わないべき？

状況による、というありきたりな答えになってしまいますが、 mutex, cond によるロック期間が短ければ sched_yield() を使用しないほうが有利、ロック期間が長かったり、PPE 上で複数のスレッドが動作する場合は sched_yield() を使用したほうが有利という感じになるのかな、、