왜 데비안 리눅스는 프로세스 당 최대 128TiB 가상 주소 공간을 허용하지만 64TiB 물리적 메모리 만 허용합니까?


23

방금 여기를 읽었 습니다 .

  • 프로세스 당 최대 128TiB 가상 주소 공간 (2GiB 대신)
  • 4GiB (또는 PAE 확장명을 가진 64GiB) 대신 64TiB 물리적 메모리 지원

왜 그런가요? 실제 메모리 지원이 커널이나 현재 하드웨어에 의해 제한되고 있습니까?

실제로 처리 할 수있는 실제 메모리보다 두 배의 가상 메모리 공간이 필요한 이유는 무엇입니까?


스왑을 추가 할 수도 있습니다.
Thorbjørn Ravn Andersen

2
그것은 많은 RAM입니다 ...
dalearn

4
@dalearn-처음으로 8 비트 마이크로를위한 뱅크 전환 메모리 확장을 통해 최대 4096KB를 확보 할 수 있다는 사실을 알게되었을 때 정확히 같은 말을했습니다.
Jules

답변:


35

이러한 한계는 데비안이나 리눅스가 아니라 하드웨어에서 나옵니다. 다른 아키텍처 (프로세서 및 메모리 버스)에는 다른 제한이 있습니다.

현재 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 포함)와 같이 필요한 플랫폼에서만 수행됩니다 .)

여러 가지 이유로 가상 메모리가 실제 메모리보다 큰 경우 유용합니다.

  • 커널이 전체 물리적 메모리를 매핑하고 가상 맵핀을위한 공간을 남겨 둘 수 있습니다.
  • 실제 메모리의 매핑 외에도 스왑, 파일 및 장치 드라이버의 매핑이 있습니다.
  • 버퍼 오버플로 를 잡기위한 가드 페이지 , ASLR 로 인한 큰 매핑되지 않은 영역 등 장소에 매핑되지 않은 메모리가 있으면 유용합니다 .

9
물리적 메모리에 대한 46 비트 제한은 Linux 메모리 맵 과 관련이 있습니다 . 커널 메모리에 물리적 메모리의 전체 매핑이 포함되어 있습니다 . 즉, 물리적 메모리는 사용 가능한 주소 공간의 1/4에만 해당 할 수 있습니다.
Stephen Kitt

@StephenKitt 의견에 대해 자세히 설명해 주시겠습니까? 나는 이해하는 데 매우 관심이 있지만 그가 인용 한 참조를 읽은 후에도 나는 그것을 얻지 못한다;)
gsi-frank

@ gsi-frank 커널이 전체 물리적 메모리를 영구적으로 매핑하는 것이 편리합니다. 따라서 2 ^ 48 주소 공간에서 2 ^ 47은 사용자 주소로, 2 ^ 46은 커널 주소로, 2 ^ 46은 실제 메모리 주소 지정입니다.
Gilles 'SO- 악마 그만해'

@ gsi-frank 고전 서적 " 자신의 32 비트 운영 체제 개발 "의 사본을 얻을 수 있다면 저자가 자신의 OS에 대해 비슷한 결정을 한 이유에 대해 상당히 깊이있게됩니다. 80386의 4GiB 가상 주소 공간을 1GiB 물리적 RAM 매핑과 2GiB 사용자 세그먼트를 포함하는 2GiB 커널 세그먼트로 분할). OS 내부에 관심이있는 사람이라면 누구나 읽어야 할 것입니다. 이해하기에 충분하지만 유용한 OS 커널이 될 수있을만큼 고급의 전체 디자인을 제공합니다.
Jules

커널 버전 4.13부터 x86-64 (및 일부 다른 아키텍처)를 5 단계 페이지 테이블 로 구축 할 수 있습니다 . x86-64의 주소 공간을 물리적 RAM의 경우 52 비트, 가상의 경우 57 비트 (4 PiB / 128 PiB). 커널 공간의 메모리 맵은 보안 문제를 유발하므로 가까운 시일 내에 변경 될 수 있습니다.
Stephen Kitt

9

이유를 모르겠지만 실제 메모리보다 두 배의 주소 공간을 지원하는 것이 유용한 7 가지 이유를 생각할 수 있습니다.

  1. 첫 번째는 추가 메모리가 필요한 응용 프로그램을 실행할 수 있도록하기위한 것입니다. 디스크로 교체하는 경우에도 마찬가지입니다.
  2. 메모리 사용을 분할하기위한보다 깨끗한 메모리 레이아웃. 예를 들어, OS는 더 높은 번호의 주소를 사용하고 응용 프로그램이 더 깔끔하게 분리 할 수 ​​있도록 낮은 번호의 주소를 남겨 둘 수 있습니다.
  3. 주소 공간 레이아웃 무작위 화가 조금 더 효과적입니다.
  4. 페이지를 실행 가능으로 표시하면 남은 메모리를 의미 할 수 있습니다.
  5. 메모리 매핑 된 I / O
  6. 메모리 할당이 더 쉽습니다. 한 번에 더 큰 청크를 할당 할 수 있습니다.
  7. 메모리 조각화 감소

1
감사! 1) 매우 분명하고 기본적이므로 질문에 부끄러워합니다.)
gsi-frank

2
(3) 정말 중요합니다. 당신은 정말 당신이 임의 추측이 거의 확실 트랩을 초래할 정도로 할당됩니다 메모리의 양보다 더 큰 규모의 주문의 가상 주소 공간을 원한다.
R ..

6

이는 하드웨어 제한 사항입니다. 현재 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 비트로 확장했습니다. 데비안 위키가 업데이트되지 않았을 가능성이 있습니다.


메모리 버스 (예 : 3D XPoint)에 직접 연결된 비 휘발성 스토리지가 문제가되고 있으며, 이는 향후 몇 년간 물리적 주소 공간에 대한 수요를 크게 증가시킬 수 있습니다 (DRAM보다 밀도가 높기 때문에 보트로드를 갖는 것이 유용합니다) 더 많은 경우에 RAM의 보트로드를 갖는 것이 유용합니다. 기술적이지 않은 기사 (또는 더 나은 자료는 Google)는 zdnet.com/article/the-volatile-memory-revolution 을 참조하십시오 . 인텔 스카이 레이크는 그것을 지원 clflush하고 clflushopt지침을 제공합니다.
Peter Cordes

1
96 개 슬롯 (예 : Tyan의 4 소켓 HPC 시스템 ) 에서 최대 12TiB의 RAM이있는 시스템을 이미 구입할 수 있으므로 64TiB는 5 년 미만입니다. 그리고 어떤 사람들은 그것들을 사고 그 정도의 RAM에 맞 춥니 다 ...
Stephen Kitt

@StephenKitt 흠, 괜찮습니다. DIMM 용량이 3 배로 2 배 가량 더 오래 걸리기 때문입니다.
derobert

실제로 64TiB의 RAM이있는 시스템을 실제로 구입할 수 있습니다 .
Stephen Kitt
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.