나는 거대한 페이지 크기와 데이터가 실제로 RAM에 기록되는 방식 사이의 관계를 이해하려고 노력하고 있습니다.
프로세스가 1GB 대용량 페이지를 사용하면 어떻게 됩니까? 쓰기가 1GB 청크 단위로 발생합니까? 내 가정이 완전히 틀린 것 같아요?
답변1
메모리 쓰기에 대한 블록 크기 정의가 두 개 이상 있습니다. 다음과 같이 생각할 수 있습니다.
- 매장 폭지침(저장 바이트, 저장 단어...), 일반적으로 1, 2, 4, 8 또는 16;
- 너비은닉처라인, 일반적으로 16 또는 64바이트(캐시 수준에 따라 라인 너비가 다를 수 있음)
- 너비메모리 버스, 소프트웨어에서 직접 관찰할 수 없습니다.
- 좀 더 합리적인 감정이있을 수 있습니다.
이 중 어느 것도 페이지 크기와 관련이 없습니다.
페이지 크기는 페이지의 속성입니다.메모리 관리 유닛. MMU 번역가상 주소(프로그램에서 사용됨)실제 주소(메모리의 물리적 위치를 지정합니다). 가상 주소를 물리 주소로 변환하는 과정은 다음과 같습니다.
- 첫 번째 수준 설명자 테이블의 주소를 찾습니다.
- 가상 주소의 가장 높은 비트를 추출하여 이를 첫 번째 수준 설명자 테이블의 인덱스로 사용합니다.
- 이 인덱스에서 L1 설명자를 디코딩하고 보조 설명자 테이블의 주소를 생성합니다.
- 가상 주소에서 더 많은 비트가 추출되어 보조 설명자 테이블에 대한 인덱스로 사용됩니다.
- 이 인덱스에서 L2 설명자를 디코딩하여 페이지 시작 주소를 생성합니다. 페이지는 MMU 테이블의 항목으로 설명되는 물리적으로 연속적인 메모리 단위입니다.
- 가상 주소의 나머지 비트를 페이지 시작 주소로 마스크하여 물리적 주소를 얻습니다.
일반적인 32비트 아키텍처는 두 가지 테이블 수준을 거치고, 일반적인 64비트 아키텍처는 3가지 수준을 거칩니다. Linux는 레벨 4까지 지원합니다.
일부 CPU 아키텍처는 특정 페이지의 크기를 늘리고 간접 참조 수준을 줄이는 것을 지원합니다. 이렇게 하면 액세스가 더 빨라지고 페이지 테이블의 크기가 줄어들지만 메모리 할당의 유연성은 떨어집니다. 대부분의 애플리케이션에서는 시간 이득이 미미하지만 작은 페이지의 유연성을 활용할 수 없는 일부 성능에 민감한 애플리케이션(예: 데이터베이스)의 경우 시간 이득이 체감될 수 있습니다.큰 페이지일반 숫자보다 적은 수준을 거치며 그에 따라 더 큰 페이지입니다.
거대한 페이지를 사용하는 소프트웨어는 종종 이를 구체적으로 요청합니다(에 대한 플래그를 통해 mmap, 참조).가상 주소 공간의 페이지 크기는 어떻게 결정됩니까?상세 사항은). 이 초기 요청 후에는 페이지 크기를 알거나 신경 쓸 필요가 없습니다. 특히, 메모리 액세스는 MMU에 의해 처리됩니다. 액세스에 관련된 소프트웨어는 없습니다.
답변2
Hugepages는 메모리 블록에 쓰는 것이 아니라 할당하는 데 사용됩니다.
일반적으로 응용 프로그램에 많은 양의 메모리가 필요한 경우 많은 "페이지"를 할당해야 합니다. 페이지는 단지 물리적 메모리의 한 조각일 뿐입니다. 일반적으로 이 블록은 몇 KB에 불과합니다. 따라서 애플리케이션이 여러 페이지에 걸쳐 많은 수의 메모리 집약적 작업을 수행하는 경우 커널은 이러한 모든 가상 메모리 페이지를 물리적 메모리로 변환해야 하며 이는 비용이 많이 듭니다.
이를 최적화하기 위해 커널은 기본적으로 기본 페이지 크기보다 큰 할당인 hugepages를 제공합니다. 따라서 수천 페이지를 할당하는 대신 몇 페이지만 할당합니다. 읽기 및 쓰기는 여전히 읽기 또는 쓰기의 크기입니다. 애플리케이션이 거대한 페이지에 10바이트 문자열을 쓰는 경우에도 여전히 10바이트 쓰기입니다.