Orz日記 by Akio Morita

_ [雑記]メモリテスト

状況は最悪かな? 2枚刺しではスロットとモジュールの組合せによらずエラー発生

1枚刺しでは現時点ではエラーは再現せず

筐体ごとお持ち込みかな?(マザー降ろすのがしんどい)

_ [お仕事]Optics Correction終了

本日のOptics Correction終了は、21:40 なんか、外は雨のようです、朝まで雨宿りかorz

_ [SAD] ISO C99

SADの Cパートを ISO C99規格で厳格にチェックし始めると、 エラーが大量に出て凹む。 EPICS Channel Access周り以外は、ほぼ修正完了

ただし、各OS毎の include headerサポート状況が異なり config/*.specの修正が泥沼... Orz

FreeBSDは、何もしないと POSIX, X/OPEN等の最新規格 + BSD拡張な include headerが提供される。で、_POSIX_C_SOURCEや _XOPEN_SOURCE マクロがあると、定義された分だけ提供する。 つまり、_POSIX_C_SOURCEや _XOPEN_SOURCEを下手に定義すると 一部の関数や typedefが提供されなくなります。

対して、Linuxは _POSIX_C_SOURCE, _XOPEN_SOURCEを明示的に 定義しないと 新しい規格に対する include headerの機能が 活性化しない...

_ [雑記] mmap(2)の OS依存な flag実装を調べてみた

なんか、いろいろ面白そうなのがありますね

64bit環境で SAD見たいな 32bitアドレッシングなものを動かすには、 MAP_ADDR32(HP-UX)とか MAP_32BIT(Linux/x86_64)が役に立ちそう。 32bit互換なアドレス空間を内に MAP_ANONYMOUSでページを作って pfalloc()に渡せば、64bitでも動く予感...

_ [雑記]KEKBの歴史が、また1ページ

アレス空洞に光子魚雷直撃

やはり、シールドが付いていなかったのが敗因か

_ [FreeBSD]ddb scripts

先日の freezeの続き

kdb.enterイベントの種別は、sys/sys/kdb.hに定義されている KDB_WHT_UNSETを除くと名前がついてるイベントは以下のとおり(stable/9 rev.228485)

• panic /* panic() was called. */
• sysctl /* Sysctl entered debugger. */
• bootflags /* Boot flags were set. */
• witness /* Witness entered debugger. */
• vfslock /* VFS detected lock problem. */
• netgraph /* Netgraph entered debugger. */
• break /* Console or serial break. */
• watchdog /* Watchdog entered debugger. */
• cam /* CAM has entered debugger. */
• ndis /* NDIS entered debugger. */
• acpi /* ACPI entered debugger. */
• trapsig /* Sparc fault. */
• powerfail /* Powerfail NMI. */
• mac /* MAC Framework. */
• powerpc /* Unhandled powerpc intr. */
• unionfs /* Unionfs bug. */
• dtrace /* DTrace action entered debugger. */

kdb.enter.defaultに resetを仕込むと再起動するようなので、 kdbに突入していることは確実なので、標準でdump&resetになるpanic以外の どの イベントでkdbに突入したかを洗い出そうと調査中

kdb.enter.camとkdb.enter.vfslockに reset仕込んだ状態で freezeしたので、それ以外ぽぃ orz

amd64なシステムで発生しないはずのイベント

• trapsig(sys/sparc64/sparc64/trap.c)
• powerfail(sys/sparc64/pci/psycho.c)
• powerpc(sys/powerpc/powermac/pswitch.c)

kernelに組み込んでないので発生しないはずのイベント

• watchdog(sys/kern/kern_clock.c by SW_WATCHDOG)
• watchdog(sys/amd64/amd64/mp_watchdog.c by MP_WATCHDOG)
• ndis(sys/compat/ndis/subr_ntoskrnl.c)
• unionfs(sys/fs/unionfs/union_subr.c)
• dtrace(sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c)

明示的な呼び出しによるイベント

• bootflags(boot_ddb boot flagで制御される kernel起動時の ddb trap)
• sysctl(debug.kdb.enter sysctlで制御される sysctlの ddb trap)
• break(debug.kdb.break_to_debugger sysctlで制御される break trap)

したがって、panic以外の調査対象イベントは...

• witness /* Witness entered debugger. */
• vfslock /* VFS detected lock problem. */
• netgraph /* Netgraph entered debugger. */
• cam /* CAM has entered debugger. */
• acpi /* ACPI entered debugger. */
• mac /* MAC Framework. */
• unknown /* KDB_WHY_UNSET */

に絞られる

この仮設の妥当性を証明するのが第一段階かな？

まあ、なんで crash dumpが取れてないかも大問題なんだけどねぇ

_ [SAD][EPICS]送信バリアの見直し

オリジナル実装の送信バリアのまとめと考察

• EPICS\$CaOpen - ca_flush_io/ca_pend無し
  • connection handler付きなので、これで正しい
• EPICS\$CaAddEvent - ca_flush_io/ca_pend無し
  • 次の送信バリアまで、queuingされている
• EPICS\$CaPut/CaPutCB - ca_flush_io有り
  • 複数のca_putを扱うためにScanすると要素毎に ca_flush_ioが走るのは非効率的
  • 送信バリア付きなら、CaWrite2のようなインターフェースが欲しい
    • 戻り値は、Nullなので引数形式を拡張しても問題ないが、どちらが便利か
      • Apply形式 f[{chid1, val1}, {chid2, val2}...] (CaWrite2の類型)
      • Map形式 f[{{chid1, val1}, {chid2, val2}...}]
  • 送信バリアを外すのも一考
    • CaMonitorクラス側で、lazy EPICS\$CaFlushIOを実装する
    • Tkinterを前提にしているので、AfterIdleを使って送信バリアをIdleTaskまで遅延させる
• EPICS\$CaClearChannel/CaClearEvent - ca_flush_io/ca_pend無し
  • 次の送信バリアまで、queuingされている
• CaOpen1/CaOpen2 - ca_pend_io有り(同期接続)
• CaClose1 - ca_pend_io有り
  • ca_clear_channelなので、ca_flush_ioで十分のはず
• CaRead1/CaRead2 - ca_pend_io有り
• CaWrite1 - 暗黙のca_pend_io有り(内部的にca_get動作を含むため)
  • ca_put直後のca_pend_ioは、ca_flush_ioで十分のはず
• CaWrite2 - ca_flush_io/ca_pend無し
  • API設計的に、ポーリングを期待していないので、ca_flush_ioするべき

_ [SAD][EPICS]API拡張の検討メモ

• CaClose1/EPICS\$CaClearChannel/EPICS\$CaClearEvent
  • chidを引数に、資源開放を行いNullを返すAPIなので、複数資源の同時開放サポートを自然に導入出来る
• CaOpen2
  • PV待ちでタイムアウトした場合、例外メッセージを返し確立済みの全接続を破棄するが、接続マネージャのバックエンドに使うには確立済みの接続は返して欲しい
  • 接続失敗を示す返り値に選択の余地有り
    • 0(無効chid slot番号) - 有効な番号と同型(Real)
    • \$Failed - RealQで有効性を判定出来る(典型的なリソース割り当てAPIの失敗戻り値)
  • =後方互換性を考えるとCaOpen3もしくはCaOpen\$を創設すべき？=CaOpen1[{pvname...}]形式でタイムアウトしたpvnameに対して$Failedを返す実装を導入
    • オリジナルのCaOpen1は、String型引数1個のみのサポートなので、引数エラー以外の互換性に影響しない
  • Tkinterを前提にして良いのなら、接続マネージャをEPICS\$CaOpenベースで実装すべき
    • 一時的な接続断に対しても自動での再接続を期待できる
    • Tkinter無しでもEPICS\$CaPendEventとSleepを組み合わせてポーリングで実装する解がある
      • Sleep時間単位で待ち時間が量子化されるので、CPU負荷と効率のバランスが難しいところ
      • デフォルトの最大待ち時間は、EPICS\$CaOpenTimeoutで拾う
      • EPICS\$CaOpenのconnection handlerが暗黙のうちにCaMonitorをロードする
      • CaMonitorパッケージロード時に評価されるCaMonitor@DoPeriodicIO[]内に含まれるAfterから暗黙のうちにTkinterが初期化される
        • 最初のca_create_channel時点で、eca_fd_register callbackが呼び出されるので、この時点でTkinterが存在しない場合、polling用の fdが行方不明になる(TkinterがDynamicLoadのケース)
        • DynamicLoad前提の場合、sadTk_CreateFileHandler wrapperにQueuingが必要となる
        • おそらく、CaMonitorの接続の場合、Tkinterにfd callbackが設定出来れば、ca_pend_ioの定期実行は不要なので、DoPeriodicIOは廃止出来る
        • ただし、EPICS\$CaOpen/CaAddEvent/CaClearEvent/CaClearChannel要求を送出するために遅延した・定期的なca_flush_ioが必要
          • CaMonitorクラスメソッドからの送出で有れば、Lazy EPICS\$CaFlushIOを仕込めば足りる
        • 以下のコードで暗黙のTkinterロード以外は、意図通りに動く

CaOpenX[pv:{__String}] := Module[{chl = EPICS$CaOpen/@pv, dt = 10e-3, timeout = EPICS$CaOpenTimeout[]},
  While[timeout > 0,
    Sleep[dt]; timeout -= dt; EPICS$CaPendEvent[];
    Print[timeout];
    If[And@@(CaConnectedQ/@chl), Break[]]];
  Map[If[CaConnectedQ[#], #, EPICS$CaClearChannel[#]; $Failed]&, chl]];

• EPICS\$CaOpen
  • 複数のPVを同時に開く拡張が考えられる(上記のCaOpenXの様な事例でMapを一つ減らせる/関数呼び出し分早くなる)
  • 後方互換性を考慮すると、EPICS\$CaOpen[chid..]形式では1引数と2引数以上で戻り値型を_Realと{__Real}で切り替える形式となる
    • 従って、リストを受けるコードを汎用で書くケースでは、Flatten[{EPICS\$CaOpen[pv...]}]となりコードが増える
      • 評価コスト的には、リストの長さ分EPICS\$CaOpenをMapから評価するのに対して、Flatten[]とList[]の評価が増えるだけなので、長いリストでは安くなるが、リスト長に線形にFlattenがSAD stackを消費する
    • 素直に、EPICS\$CaOpen[{pv...}]をサポートする方が簡単？=実装した
      • 内部エンジンをit/iaペアを受ける1引数バックエンド(String/String-Listのみサポート)と引数検査を行うフロントエンドに分割して実装する=
• CaConState1
  • 戻り値が、独自フォーマットなのが使い難い
  • 接続状態判定だけなら、真偽値で欲しい
    • =新説するなら、=CaConnectedQ=辺りか？=を実装した
    • Query関数にするなら、無効な引数に対しては、Falseを返すべき？

_ [SAD]mmap_utils回りの書き換え済みコードについての覚書

tffsmatchで割り当てた領域がtffscalcに渡しているケースで、tffscalc内部で並列化する場合に、並列リージョンからの書き戻し動作の挙動が変わっていないかソースを精査する必要あり

_ [SAD][EPICS]EPICS backendの残作業まとめ

• 実働・通信テスト
• CaOpen/CaClose/CaRead/CaWrite wrapperの再実装(Packages/CaSad.n)
  • 複数レコードへの接続要求の効率的な処理(拡張されたCaOpen1)
  • CaCloseのサポート
    • 現行実装では、チャンネル切断時に二度とアクセス出来なくなる(chidの再生成をサポートしていない)
  • 可能なら、EPICS\$CaOpenベースへ移行する
    • connection handler付きであれば、IOC再起動時などは自動での再接続を期待出来る
• EPICS\$CaPut/CaPutCBから ca_flush_ioの排除
  • CaMonitorクラスのLazy FlushIO化(Put/PutCB/Start/Stop/Constructor/Destructor)
• TkinterのDynamic Loading対応
  • Tk_CreateFileHandler wrapperでのQueuingサポート
• CaMonitorから DoPeriodicIOの排除
  • 送信バッファのca_flush_ioは、Lazy FlushIOが実施
  • ca_pend_eventは、eca_fd_callbackが担当する

_ [SAD]itfmaloc系の書き換え

• src/tffswake.f以外のFortranコードは書き換え完了
  • 動作確認等を実施すべき
• Cコードに当該呼び出しを含むモジュールが存在する
  • ExtendedTwiss
  • Wake
  • Standard/SpaceCharge/Scheff
  • Standard/SpaceCharge/Scheff/MatrixFunctions
  • 効率的なインターフェースを考える必要がある
  • 動的な2次元配列型をC上で効率的に扱えるか？
• 実数配列から、リストを作る操作で、書き方がブレている
  • itfm2lの様な関数で表現を統一すると読みやすくなる(要検討)
• tffswakeに関しては、beamline element毎にポテンシャルを展開した配列を管理するのに、SADのobject heapを使っている
  • ただし、ルートノードは COMMONブロック上に存在している
  • 配列pointerの割付配列を用意して書き換えることを検討する