SGI Origin 350でSMP - syuu1228's blog

まだ分かってない事も多いのだが、追々調べる。

Originのコンセプト

これは、ディスプレイコネクタもなく２Uである事からも分かるように、デスクサイドに置くようなタイプのマシンでなくラックに詰め込んで何らかの処理（レンダリングファーム用？それともHPCなのか？）に使う為にデザインされたマシン、だと思う。
大きなポイントは、クラスタリングをハード的にサポートしてる事。
NUMALink用ケーブルを持ってきて二台のOrigin 350を繋ぐと、OSからは一台の高スペックなOriginに見えるような仕組みになっている。シェアードメモリ型で、NUMAアーキテクチャ。
スイッチがあれば４台、８台構成も可能で、最初から４／８台でクラスタ組んだラック入りのシステムはOnyxって名前で販売されていた模様。

で、この仕組みがあるが故に色々と複雑な仕様になっててややこしい。

CPUIDについて

Octaneの時は#0と#1だけが存在していて、プライマリプロセッサは常に#0だった。
しかし、Originでは任意のCPUをPROMプロンプトから有効・無効出来る上にプライマリプロセッサを指定する事が出来る。
また、他のノードとクラスタを組むのが前提なせいか、２プロセッサのOrigin 350のCPUIDは#0と#2である。

OpenBSD的にはプライマリプロセッサがcpu0だしautoconfでcpu0の次がcpu2というattachは出来ないはずなので、これに対応するには論理CPUIDと物理CPUIDを別々に管理する必要がある（今はわけてない）。

メモリ管理

基本的にはローカルノードプロセッサ間においても、ノード間においても共有メモリでコヒーレントであるので透過的なはず。
だが、敢えて一部に非共有エリアを持っている。
これをケアしないとメモリがインコンシステントになってしまう。

まず、CAlias空間というのがあって、これは物理アドレス空間の先頭数MBがノード間で非共有になっている。
容量はCAliasレジスタで変更出来る（このレジスタがどこにあるのかは未だ調べていない。性質的に、CP0レジスタではなくてコントローラデバイスのハードウェアレジスタかな？）

一方、先頭128KBのメモリはそれぞれのプロセッサで排他的に使う領域として予約されている。
こちらは非共有というか、別のものが見える為の仕掛けがしてある。

cpu0から見た0-64KBは物理メモリの0-64KB、64-128KBは物理メモリの64-128KBが見えるが、
cpu1から見た0-64KBは物理メモリの64-128KB、64-128KBは物理メモリの0-64KBが見えるようになっているのだ。

なので、CPU固有のデータを持ちたかったら先頭64KBに置けばいい。他のプロセッサには邪魔されない。
が、しかし、この空間にexception vectorとかも存在するので、初期化時にきちんとコピーしてあげないとちゃんと動かない。

他は？

まぁ、他にも色々と面倒な仕掛けがあるんだろう。特にメモリ空間はノードを超えて共有しているが為に色々な仕掛けが入っていると思われる。
ドキュメントは手にしたが、まだきちんと読めてない。