분명히 이것은 mmap사용 가능한 가장 큰 가상 주소 공간 블록의 크기에 의해 제한됩니다. 그러나 64비트 시스템이 있다고 가정하면 대부분의 경우 이는 거의 무제한입니다. 또한 스왑 파티션이 구성되어 있지 않다고 가정합니다.
익명 매핑의 경우 크기는 사용 가능한 실제 메모리의 총량으로 제한되어야 합니다.
하지만 파일 기반 매핑의 경우 매핑 크기가 물리적 메모리 양의 최대 X배까지 될 수 있는 것처럼 물리적 메모리 양에 따른 제한이 있는지 알고 싶습니다. 아니면 mmap가상 주소 공간 제한에 도달하지 않는 한 임의로 큰 파일을 단일 블록으로 매핑할 수 있습니까? 예를 들어 RAM이 32GiB인 경우 mmap1TiB 디스크 파일을 성공적으로 생성할 수 있나요?
만약을 대비해 Linux에 대해 구체적으로 물어보세요. (64GiB 파일을 사용해 보았는데 작동하는 것 같았습니다. 아쉽게도 그보다 더 많은 여유 디스크 공간이 없습니다.)
답변1
매핑된 파일을 사용한다고 해서 mmap()파일이 물리적 메모리에 복사되는 것은 아니므로 제한할 이유가 없습니다. 전체 파일을 가상 주소 공간으로 표현할 수 있다면 매핑이 가능합니다. 작동 방식은 각 페이지가 메모리에 상주하지 않으므로 해당 페이지에 액세스하면 페이지 오류가 발생한다는 것입니다. 커널은 이 기회를 투명하게 활용하여 파일의 해당 부분에 액세스합니다. 이를 통해 사용자 프로세스는 여러 작업을 수행하지 않고도 매우 큰 파일을 조작할 수 있습니다.낮은 효율성 read(), write()및 seek()루프(여전히 다음과 같은 컨텍스트 전환이 발생하지만)무엇실제로 VFS를 처리해야 합니다.)
익명 매핑에 유의하세요.할 수 있는다음과 같은 경우 남은 실제 메모리를 초과합니다.메모리 과잉 할당각 가상 페이지가 페이지 테이블에 설정되어 있으므로 활성화됩니다.가리키는물리적제로 페이지. 모든 읽기는 0을 반환하지만 쓰기는 페이지 오류를 일으키고 커널은 데이터를 저장할 여유 물리적 페이지를 찾아야 하며, 이때 페이지 테이블을 업데이트할 수 있습니다. 물론 이를 위해서는 충분한 물리적 메모리 + 스왑 공간이 필요합니다. 오버커밋은 대부분의 메모리 할당자가 대부분이 사용되지 않더라도 힙에 대한 메모리를 공격적으로 요청하기 때문에 유용한 최적화입니다.
파일을 매핑할 수도 있습니다.주소 공간보다 큼하지만 한 번의 통화로 한꺼번에 완료할 수는 없습니다 mmap().
부록으로, 64비트 시스템에서도 전체 64비트 주소 공간을 사용하지 못할 수 있습니다.
$ grep -m1 "address sizes" /proc/cpuinfo
address sizes : 39 bits physical, 48 bits virtual
해당 시스템에서는 48비트 가상 주소 공간이 두 개로 분할되므로 크기가 2 47바이트 또는 128TiB인 파일을 매핑할 수 있습니다(실제로는 더 작습니다.일부주소 공간이 이미 사용 중입니다).