ワンレベルストア - oraccha/omicron GitHub Wiki
悩める子羊たちに捧げる。
もしくは,ワンレベルストレージ.
歴史的には,初めて仮想記憶を実装した英国の計算機 Atlas で使われた用語です.
ワンレベルストアは良くも悪くもフォン・ノイマン型アーキテクチャを忠実に実現したものと言える.そして,完全ワンレベルストアなシステムは現実的ではないだろう.Multicsしかり,V4しかり.というのはノイマンモデルではメモリが重要な役割を果たしており,メモリ上のプログラム,データにはクラッシュなど,常にセキュリティの問題が付きまとっているからである.そこで,通常のOS(MVSかつ2-level storage)は,入出力に関する部分をノイマンモデルから切り離し,さらにアドレス空間を分けることで,モデルの性質の影響を押え,セキュアにしようとしている.ワンレベルストアでこれらと同程度にセキュアなシステムを実現することは課題の一つである. . もう一つの課題はアドレス空間のフラグメンテーションを解消するためにコンパクションをいかに行うかということだろう.ひょっとするとGCみたいな機構を導入する必要があるのかもしれない.
プロセッサ,コア(メモリ),入出力の速度差がさほどなかった時代の計算機では,単純にワンレベルストアを実現しても有効だったかもしれないが,現在の計算機環境においては,これらの間には数桁の速度差があることを考慮する必要がある.このように速度差のあるデバイス,すなわち高速バスと低速バスが存在する場合,計算機を効率的に利用し,性能を向上するためにキャッシュ技術が利用されている. . キャッシュを始めとした多記憶階層も,局所性を基礎として仮想的なノイマンモデルを提供していると考えることができる.そこで,キャッシュミスが発生した場合は,モデルの一貫性を保証するためのオーバヘッドが伴う.はたしてこのような記憶階層を持つ計算機環境において,ワンレベルストア,ノイマンモデルは性能上,有効なモデルと言えるのだろうか? . 例えば,すべての資源はメモリ上に存在するといっても,実際には最新のデータはCPUキャッシュ上に存在するわけで,キャッシュをパージ(purge)しない限り,メモリに反映されないわけだ.
ワンレベルストアとは,分散環境を無視すれば(分散共有メモリで実現する方法はある)システムのすべての資源がアドレスで一意になるということである.Unixのようにすべての資源をファイルにあてはめる必要がなく,ファイルシステム,ファイル名という呪縛から解放される.ストリングシンボルの利点はCLIなどテキストベースのプログラムから正確に指定できることだが,GUIシステムではストリングシンボルによる識別は必須ではないし,逆に面倒なファイル操作が必要になる.ストリングシンボルは検索の精度を上げるためのイメージシンボルの従属物にしてしまえ!! (→ MySymbolicSystem)
おおお。かっこいい文章ですぅ。兄弟頁も色々読みました。 (つーかPalmにコピって歩きながら読んでいたり(^^;)
↑ お恥ずかしい...
OS/omicron からの続きですが、「2次元」ってのはもしかして、「確保(?)したメモリブロックの先頭アドレス(の別名)」および「そのブロックの中のオフセット値」の組み合わせ、みたいなものという意味かと理解しましたが、合っていますか? -戯
いにしえの8086の「セグメント」を、実装方法も活用形態も数億倍マシにした(^^;ようなものかなと思いました。
#8086の悲劇は、セグメントを「役立てる」ことを、(殆どだれも)しなかった and 出来なかった(64kでは狭すぎるので)点にある、のかなと。
はい。悩んでます(^^;
↑ V4 でも実装にはセグメントを利用してます. 結局,x86 のセグメントは偽りのセグメントというか,結局リニアアドレスにマッピングするので,厳しい面はあります.
セグメント命令は速くならないし,それ以前に, IA64 にはセグメント命令は残るのかなぁ? ん〜,やっぱりプロプライエタリな流れに逆らっているとこういうのは厳しいですね.
アーキテクチャ屋から見れば,x86 なんて,間違った(^^;)プロセッサなんだろうけど.
なんか採用したCPU(x86)の仕様で色々大変だったってな文脈でしたよね。 もしかして Crusoe って「本来は」、より良い(使いやすい)CPUとか、非メジャーな構造のOSと親和性の高いCPUとか、そういうモノを仮想的に実現するためにこそ使うべきチップなのかな、と思いました。単なるx86エミュでは勿体ないような気が。
↑ 本当に最近はハードウェアの敷居が低くなってきたかなとか思います. FPGA とか PLD とかで遊んでみたいっスね.
OS/omicron も初期のころはハードウェアと並行開発していたみたいです. あまりにもデバッグが大変で(信頼できないハードの上で,信頼できないソフトを動かすんだから...)ハードウェアは断念したみたいですが.
東大では,CPUの設計からアプリケーションまでやる実験があるって聞きましたが,うらやましいですね.実際にやった学生の意見を聞いてみたいです.
ファイルがいきなりポインタ経由で見えるって奴は、仮想的なものとしては、oopなライブラリで「FileStream型」なんてのがしばしば作られてるようですね。あれを仮想じゃなくて本物として実装するとV4のソレになる…んですよね?
↑ そうですね.V4 の場合は,言語被依存というかインストラクションレベルでこの機構が働きますからね.
「ファイルシステムがなければ OS じゃない」っていう人もいますが,ファームウェアや組込みOS みたいなリソースが少ないものでも,こんな OS はありだと思います.
PDA との親和性は悪くないかなとは思います.PalmOS を知ったときも,なんか近いものを感じましたし.ただ,あまりにもスケーラビリティがない設計ではありますが.
- 意外とワンレベルストアの考え方と相性がいいのは不揮発性メモリを持つPDAなのかもしれない.物理的に二次記憶を持たず,すべてのプログラム,データが単一記憶上に存在するのだから.PalmPilotのアーキテクチャを知ったときはそう思った.PalmOSの実装はハンドルとポインタにおける一種の PointerSwizzling など,実記憶系でMMUの機構を提供している感じだが,参考になる点はあると思う.
- PalmOS は ClassicMac に影響を受けているので,TikiGuion:ClassicMacのメモリ管理は参考になるかも.
- TikiSuz:ぐるぐるこめんと/GCその後にもありますけど,データの実体がネットワーク上に存在し,ローカルマシン上にはそのキャッシュしか存在しないという流れは,確かにあると思います.そのときローカルファイルシステムは必要になるのか.メモリ(キャッシュ)管理はどうなるか考えると,ワンレベルストア的な部分は欲しくなるかなと思います.ただし,ちょっと下にも書いてますが,SASOSうんぬんというのじゃなくて,どのレベルでサポートするかが問題になってきますが.
ディスクキャッシュを使い始める&使い終わる(吐き出す)べきタイミングって、「データセグメント(?)」が「ルーチンセグメント」から何回参照されてるか?という参照計数で、決定できたりする、のかなあ…。データセグメント同士の参照は「処理が起きているかどうかに関係ない」ので、遅い二次媒体に収まっていても痛くも痒くもないけど、ルーチンセグメントからの参照は、今まさに高速なアクセスが必要になる(だろう)から…
悩んでます(笑)
↑ 厳密な意味での ワンレベルストア では,強い一貫性が求められると言うか,AP からは同じイメージ(メモリ)が見えるはずだと思いますが,そこは性能とのトレードオフが必要になってくると思ってます. .
分散環境とか考えたら特に.
- V4 は C 言語レベルでワンレベルストアを実現しようとしたのだけれども,C 言語は低水準すぎるので,ワンレベルストアを保証するためのオーバヘッドが大きいし,スタックは丸見えなので,細粒度の保護は難しいという欠点がある.
鳩山をプラットホームにやろうとしていることは,もっと言語的に高水準なところ(言語層,つまり仮想マシン層)でこのような性質を実現しようということにつながると思う.
- Hayakawa さんが言うところの OCT(OLS Consistency Time,ワンレベルストア的性質を保っている時間) は実プロセッサの命令レベルよりも言語レベルでの方がはるかに長い.つまり,プログラムは言語が提供する箱庭の中で実行されるので,言語の壁をやぶるときまでそのペナルティは遅延されることになる.
- タスク間でのデータ共有を効率的に行なうために研究された SASOS というのは,一つの手段ではあるけど,アドレス空間がシングルであるかマルチであるかというのは本質的な問題じゃないと改めて感じている.
- つまるところ,もっと考える必要があったのはデータの抽象的リンク表現であったはずだ.我々はデータ表現モデルをおざなりにし,ワンレベルストアやダイナミックリンクという機構に走りすぎた.ワンレベルストアが特長と言うのは主客が逆転した話である.
トランザクション,履歴管理との相性みたいことを考えてます. . 履歴とかリムーバブルメディアをどのようなアドレス(or 名前)空間にマッピングするかってのは悩ましいのですが.
- 例えば2次記憶がRAIDみたいにstripingされていたとすると,1台のディスクがクラッシュしたらリンク関係を含め復旧は容易かとか.
- ん〜,mirroringと併用すれば大丈夫なのかな.
あと,ダイナミックリンク の性格上,最初のアクセスにかかるコストは仕方ないと思ってます.関数がどの程度呼び出されるかという,アプリケーションの性質にもよりますが.