- 프로세스 당 최대 128TiB 가상 주소 공간 (2GiB 대신)
- 4GiB (또는 PAE 확장명을 가진 64GiB) 대신 64TiB 물리적 메모리 지원
왜 그런가요? 실제 메모리 지원이 커널이나 현재 하드웨어에 의해 제한되고 있습니까?
실제로 처리 할 수있는 실제 메모리보다 두 배의 가상 메모리 공간이 필요한 이유는 무엇입니까?
- 프로세스 당 최대 128TiB 가상 주소 공간 (2GiB 대신)
- 4GiB (또는 PAE 확장명을 가진 64GiB) 대신 64TiB 물리적 메모리 지원
왜 그런가요? 실제 메모리 지원이 커널이나 현재 하드웨어에 의해 제한되고 있습니까?
실제로 처리 할 수있는 실제 메모리보다 두 배의 가상 메모리 공간이 필요한 이유는 무엇입니까?
답변:
이러한 한계는 데비안이나 리눅스가 아니라 하드웨어에서 나옵니다. 다른 아키텍처 (프로세서 및 메모리 버스)에는 다른 제한이 있습니다.
현재 x86-64 PC 프로세서에서 MMU는 48 비트의 가상 주소 공간을 허용 합니다 . 즉, 주소 공간이 256TB로 제한됩니다. 커널 주소를 사용자 주소와 구별하기위한 1 비트로 프로세스 주소 공간에 128TB를 남겨 둡니다.
현재 x86-64 프로세서에서 실제 주소는 최대 48 비트를 사용할 수 있으므로 최대 256TB를 가질 수 있습니다. amd64 아키텍처가 도입 된 이후 한계가 점차 높아졌습니다 (정확하게 리콜하면 40 비트에서). 주소 공간의 각 비트는 약간의 배선 및 디코딩 로직 (프로세서가 더 비싸고 느리고 더 뜨겁게 됨)을 소비하므로 하드웨어 제조업체는 크기를 줄이려는 동기가 있습니다.
리눅스는 물리적 메모리가 커널 공간에 완전히 매핑 될 수 있기 때문에 물리적 주소는 2 ^ 46까지만 허용합니다 (따라서 최대 64TB 만 가능). 주소 공간은 48 비트입니다. 커널 / 사용자를위한 1 비트는 커널 주소 공간을 위해 47 비트를 남깁니다. 그 중 절반은 대부분 실제 메모리를 직접 다루고 나머지 절반은 커널이 필요한 것을 매핑 할 수있게합니다. (리눅스는 전체 메모리를 동시에 매핑 할 수는 없지만 물리적 복잡성을 처리 할 수 있지만 복잡성이 추가되므로 x86-32 (PAE 포함) 및 armv7 ( LPAE 포함)와 같이 필요한 플랫폼에서만 수행됩니다 .)
여러 가지 이유로 가상 메모리가 실제 메모리보다 큰 경우 유용합니다.
이유를 모르겠지만 실제 메모리보다 두 배의 주소 공간을 지원하는 것이 유용한 7 가지 이유를 생각할 수 있습니다.
이는 하드웨어 제한 사항입니다. 현재 x86_64 / amd64 하드웨어는 48 비트 가상 주소와 다양한 크기를 구현할 수 있습니다 (구현에 따라 다릅니다. 예를 들어, 내 워크 스테이션은 36 비트 만 지원합니다). Linux 커널은 가상 주소 공간을 절반으로 분할합니다 (x86에서와 마찬가지로 절반은 커널, 절반은 사용자 공간을 사용).
그래서 당신은 얻을 :
2⁴⁸ 바이트 ÷ 2 = 2⁴⁷ 바이트 = 128TiB
실제 주소 크기는 실제 크기이므로 종종 더 작습니다. CPU의 핀 / 패드, 트랜지스터, 연결 등과 보드의 트레이스 라인을 차지합니다. 아마도 칩셋에서도 동일합니다. 프로세서 코어 또는 소켓의 설계 수명 동안 상상할 수없는 많은 양의 램을 지원하는 것은 의미가 없습니다. (각각 32 개의 DIMM 슬롯과 64GiB DIMM을 사용하더라도 여전히 2TiB에 불과합니다. DIMM 용량이 연간 두 배로 증가하더라도 64TiB에서 5 년이 걸립니다.
Peter Cordes가 지적한 대로 사람들은 이제 3D XPoint 와 같은 비 휘발성 저장소 를 메모리 버스에 연결하여 주소 공간이 부족할 수 있습니다. 최신 프로세서는 물리적 주소 공간을 48 비트로 확장했습니다. 데비안 위키가 업데이트되지 않았을 가능성이 있습니다.
clflush
하고 clflushopt
지침을 제공합니다.