kernel 解析 take.2 (syscall だけ見るって無理があるわな)-CELLプロセッサ
2 つしかない SPE 用の syscall (sys_spu_create,...
2 つしかない SPE 用の syscall (sys_spu_create, sys_spu_run) くらい見ておくか、と思って 見始めたらどんどん深みにはまって気づいたら最深部までいってます。そのおかげでなかなか興 味深いことがわかったのでまずはメモということで。
- SPE プログラム用のスケジューラがあり、物理数以上の SPE プログラムを扱うことが可能。
-
ディスパッチ時に退避、復帰される SPE のコンテキストには、128 個ある
GPR (General-Purpose Register)、256KB の LS (Local Store)、MFC 制御レジスタ等
のほぼ全ての資源が含まれる (巨大コンテキスト)。
(参考 include/asm-powerpc/{spu.h,spu_csa.h}) -
コンテキストが巨大ということは復帰、退避処理も長いです。退避 54 STEP、復帰 75 STEP って
、、、
(参考 arch/powerpc/platforms/cell/spufs/switch.c) - PPE から制御できる資源は PPE が退避、復帰する。が、SPE の GPR は PPE からは制御できないので、、
-
GPR を退避、復帰するために、まず PPE から LS を 16KB だけ MFC を使って退避し、空いた領域に
プログラムを別途転送、このプログラムから GPR の退避、復帰と LS の残り 240KB (256KB - 16KB) の
退避、復帰を行っている。
(参考 arch/powerpc/platforms/cell/spufs/spu_{save,restore}.c) -
SPE のプログラムは、PPE 上の対応する SPE thread の優先度をそのまま使用している。
ということは libspe-1.1.0 が SPE thread の優先度変更に対応していないので、現状では
やっぱり SPE プログラムの優先度変更はできない。
(参考 arch/powerpc/platforms/cell/spufs/context.c: spu_acquire_runnable())
なんか、スゴい、、
