アカウント名:
パスワード:
64bit CPU も忘れずに。
同時にOSも64bitに。
そうっ!! 40bit しか明け渡してくれない Linux なんぞではなく!!!
…ちなみに、本当にアドレス空間が 64bit ある OS って何だろう…
>40bit しか明け渡してくれない Linuxチップのアドレスバス幅に揃えているからではないでしょうか。チップのバス幅を超えるメモリ管理までは、osではまかない切れませんよ、みたいな?
// 1024PBのメモリで、一体ナニをなさろうとしておろれるのです?
一応こっちに先に反応しておくと
10bit: Kilo20bit: Mega30bit: Giga40bit: Tera50bit: Peta60bit: Exa70bit: Zetta80bit: Yotta
なので 64bit は 16Exa byte です。
.
で。「物理メモリとしての幅」は確かにチップセットに縛られますが、 仮想空間 はそんなものに縛られる必要はありません。世の中には mmap() というすばらしいシステムコールがあって、ファイルだろうがなんだろうが「メモリ上に直接マップしてくれたまへ」と言う事ができる。たとえば Blue Ray Disk の片面8層 [tatsuzin.jp]なんか200Gbyte あるらしいんですが、アドレス空間さえあれば mmap() でディスク全部を mmap() でマッピングすることができる。
プログラムは、まるで 200Gbyte のメモリが存在するかのようにランダムアクセスをかける。すると、必要に応じて kernel がひーこら言いながら、BD の必要な部分を読み込んでメモリ上に展開し、ここしばらくつかってなかった部分は 破棄してくれる (か、変更があったならば Write Back するんだろうが、多分この場合の BD は書けないんだろうな)。
これは 2Tbyte の HDD だろうが、それを 18台つないだ Raid6 だろうが、一緒。『全てはメモリ上に…』を仮想的に実現できるのです。すると、従来、フィルター型のプログラミングが必要だったものが、お手抜きコーディング可能に…。
.もっともっと言うと、今のファイルシステムには Sparse File を扱う能力があります。つまり、「最初の1バイト目の辺りに xxxx が書いてあって、10Mbyte 目に yyyy が書いてある必要があるが、その途中は全く参照しないのでごみが入ってても構わない」などという疎なファイルを考えてください。従来は 10Mbyte のディスクを食っていたこのようなファイル。最近の Sparse File 対応ファイルシステムだと、最初の 1block と 10Mbyte 目の 1block の 2block 分しかディスク要らない。途中の部分はファイルシステム的に「ブロックはまだ割り当てられていない」状態。これは仮想アドレスで「物理的にはアドレスはあるが、メモリは割り当てられていないページ」があるのと同じ状態がファイル上でも実装できる、って事です。
すると、1Mbyte しかは要らないはずのフロッピーディスク上に、1Yotta の Sparse File を作ることさえ可能なのです。(べつに1024Yotta だって作れる。ようするに最後の 1block 分だけ存在して頭からそこまでは全部「空」なファイルを作ればいいのですから)
そういうものを mmap() しようとすると、やはり「アドレス空間的には」1Yotta 必要なのですよ。物理メモリ的には(管理用のメモリ以外では) 最後の 1block 分だけあればいいんですけどね。もちろん、20Tbyte 目に1バイト書き込むと、そこの page が予約されてイメージが準備されると同時にファイルシステム上にも 1block の予約が実施され、イメージが書き込まれ、管理テーブルが膨大に作り変えられると言う… (裏で生じる作業量を考えるとガクブル…)。
というわけで、 アドレス空間は広大無辺に必要 なのです。
# だから Ottawa Linux Symposium でも言ったように、ファイルシステムは 1024bit サポートが…
参考になりました。特にSparse Fileの記述からは、新しい知見を得る事ができました。ありがとうございます。
// bit容量換算のご指摘も感謝! です
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
しかし 32bit ではアドレス空間が足りない (スコア:2, すばらしい洞察)
64bit CPU も忘れずに。
fjの教祖様
Re: (スコア:1)
同時にOSも64bitに。
Re: (スコア:1)
そうっ!! 40bit しか明け渡してくれない Linux なんぞではなく!!!
…ちなみに、本当にアドレス空間が 64bit ある OS って何だろう…
fjの教祖様
Re: (スコア:1)
>40bit しか明け渡してくれない Linux
チップのアドレスバス幅に揃えているからではないでしょうか。
チップのバス幅を超えるメモリ管理までは、
osではまかない切れませんよ、みたいな?
// 1024PBのメモリで、一体ナニをなさろうとしておろれるのです?
Re:しかし 32bit ではアドレス空間が足りない (スコア:1)
一応こっちに先に反応しておくと
10bit: Kilo
20bit: Mega
30bit: Giga
40bit: Tera
50bit: Peta
60bit: Exa
70bit: Zetta
80bit: Yotta
なので 64bit は 16Exa byte です。
.
で。「物理メモリとしての幅」は確かにチップセットに縛られますが、 仮想空間 はそんなものに縛られる必要はありません。
世の中には mmap() というすばらしいシステムコールがあって、ファイルだろうがなんだろうが
「メモリ上に直接マップしてくれたまへ」
と言う事ができる。たとえば Blue Ray Disk の片面8層 [tatsuzin.jp]なんか200Gbyte あるらしいんですが、アドレス空間さえあれば mmap() でディスク全部を mmap() でマッピングすることができる。
プログラムは、まるで 200Gbyte のメモリが存在するかのようにランダムアクセスをかける。すると、必要に応じて kernel がひーこら言いながら、BD の必要な部分を読み込んでメモリ上に展開し、ここしばらくつかってなかった部分は 破棄してくれる (か、変更があったならば Write Back するんだろうが、多分この場合の BD は書けないんだろうな)。
これは 2Tbyte の HDD だろうが、それを 18台つないだ Raid6 だろうが、一緒。『全てはメモリ上に…』を仮想的に実現できるのです。すると、従来、フィルター型のプログラミングが必要だったものが、お手抜きコーディング可能に…。
.
もっともっと言うと、今のファイルシステムには Sparse File を扱う能力があります。つまり、
「最初の1バイト目の辺りに xxxx が書いてあって、10Mbyte 目に yyyy が書いてある必要があるが、その途中は全く参照しないのでごみが入ってても構わない」
などという疎なファイルを考えてください。従来は 10Mbyte のディスクを食っていたこのようなファイル。最近の Sparse File 対応ファイルシステムだと、最初の 1block と 10Mbyte 目の 1block の 2block 分しかディスク要らない。途中の部分はファイルシステム的に「ブロックはまだ割り当てられていない」状態。これは仮想アドレスで「物理的にはアドレスはあるが、メモリは割り当てられていないページ」があるのと同じ状態がファイル上でも実装できる、って事です。
すると、1Mbyte しかは要らないはずのフロッピーディスク上に、1Yotta の Sparse File を作ることさえ可能なのです。
(べつに1024Yotta だって作れる。ようするに最後の 1block 分だけ存在して頭からそこまでは全部「空」なファイルを作ればいいのですから)
そういうものを mmap() しようとすると、やはり「アドレス空間的には」1Yotta 必要なのですよ。物理メモリ的には(管理用のメモリ以外では) 最後の 1block 分だけあればいいんですけどね。もちろん、20Tbyte 目に1バイト書き込むと、そこの page が予約されてイメージが準備されると同時にファイルシステム上にも 1block の予約が実施され、イメージが書き込まれ、管理テーブルが膨大に作り変えられると言う… (裏で生じる作業量を考えるとガクブル…)。
というわけで、 アドレス空間は広大無辺に必要 なのです。
# だから Ottawa Linux Symposium でも言ったように、ファイルシステムは 1024bit サポートが…
fjの教祖様
Re:しかし 32bit ではアドレス空間が足りない (スコア:1)
参考になりました。
特にSparse Fileの記述からは、新しい知見を得る事ができました。
ありがとうございます。
// bit容量換算のご指摘も感謝! です