明らかに、これはmmap利用可能な最大の仮想アドレス空間ブロックのサイズによって制限される。ただし、64ビットシステムがあると仮定すると、ほとんどの場合、これはほとんど無制限です。また、スワップパーティションが構成されていないと仮定します。
匿名マッピングの場合、サイズは使用可能な物理メモリの総量に制限する必要があります。
しかし、ファイルベースのマッピングでは、マッピングサイズが物理メモリの最大X倍になるように、物理メモリの量に応じた制限があるかどうかを知りたいです。またはmmap、仮想アドレス空間の制限に達していない限り、ランダムに大きなファイルを単一のブロックにマップできますか？たとえば、RAMが32GiBの場合、mmap1TiBディスクファイルを正常に作成できますか？
もしそうなら、Linuxについて具体的に尋ねてください。 （64GiBファイルを試してみましたが、うまくいきました。残念ながら、それ以上の空きディスク容量はありません。）
ベストアンサー1
マッピングされたファイルを使用してもmmap()ファイルが物理メモリにコピーされるわけではないので、制限する理由はありません。ファイル全体を仮想アドレス空間として表現できる場合は、マッピングが可能です。動作方法は、各ページがメモリに常駐していないため、そのページにアクセスするとページエラーが発生することです。カーネルはこの機会を透過的に活用してファイルの適切な部分にアクセスします。これにより、ユーザープロセスは、複数の操作を行わずに非常に大きなファイルを操作できます。低効率 read()、write()およびseek()ループ（まだ次のようなコンテキスト切り替えが発生しますが）何実際にはVFSを処理する必要があります。）
匿名マッピングに注意してください。できる次の場合、残りの物理メモリを超えています。メモリ過剰割り当て各仮想ページがページテーブルに設定されているため有効になります。指す物理ゼロページ。すべての読み取りはゼロを返しますが、書き込みはページエラーを引き起こし、カーネルはデータを保存するための空き物理ページを見つける必要があり、その時点でページテーブルを更新できます。もちろん、これには十分な物理メモリ+スワップスペースが必要です。オーバーコミットは、ほとんどのメモリアロケータがほとんど使用されていなくてもヒープのメモリを積極的に要求するため、便利な最適化です。
ファイルをマッピングすることもできます。アドレス空間より大きいただし、1回の通話で一度に完了することはできませんmmap()。
付録では、64ビットシステムでも64ビットアドレス空間全体を使用できない可能性があります。
$ grep -m1 "address sizes" /proc/cpuinfo
address sizes : 39 bits physical, 48 bits virtual
このシステムでは、48ビットの仮想アドレス空間が2つに分割されているため、サイズが2 47バイトまたは128TiBのファイルをマッピングできます（実際には小さくなります）。一部アドレス空間はすでに使用中です。