Linux 시스템의 기본 페이지 크기가 4KB인 이유

우리 모두 알고 있듯이 Linux는 페이지 단위로 메모리를 관리합니다. 디스크에서 메모리로 데이터를 로드하거나 메모리에서 다시 디스크로 데이터를 쓰는 경우 운영 체제는 페이지 단위로 작동합니다. 이는 또한 1바이트의 데이터만 디스크에 쓰는 경우 운영 체제도 플러시해야 함을 의미합니다. 전체 페이지의 모든 데이터를 디스크에 저장합니다.

Linux에서는 작업에 보통 크기의 메모리 페이지를 사용할 수도 있고 대부분의 프로세서에서 메모리 페이지의 기본 크기가 4KB이지만 일부 프로세서에서는 8KB, 16KB를 사용할 수도 있습니다. 또는 64KB를 기본 페이지 크기로 사용합니다. 일반적인 메모리 페이지 크기 외에도 다양한 프로세서가 다양한 대용량 페이지 크기를 지원합니다. 예를 들어 x86 프로세서에서는 2MB 크기의 메모리 페이지를 사용할 수 있습니다.

4KB 메모리 페이지는 역사적인 유물이 되었습니다. 이 페이지 크기는 1980년대부터 널리 채택되었으며 오늘날에도 여전히 남아 있습니다. 오늘날의 하드웨어는 과거보다 풍부해졌음에도 불구하고 우리는 여전히 과거로부터 물려받은 4KB의 메모리 페이지 크기에 갇혀 있습니다. 일반적으로 아래 그림과 같이 메모리를 설치할 때 메모리 모듈의 사양을 명확하게 확인할 수 있습니다.

그림 1 – 랜덤 액세스 메모리

현재는 4KB 메모리 페이지 크기가 최선의 선택이 아닐 수도 있습니다. 8KB 또는 16KB가 더 나은 선택일 수도 있지만 이는 과거 특정 시나리오에서 절충된 사항입니다. 이 기사에서는 4KB라는 숫자에 너무 집착해서는 안 됩니다. 이 결과를 결정하는 여러 요소에 더 많은 관심을 기울여야 합니다. 그래야 유사한 시나리오에 직면할 때 이러한 측면에서 최선의 선택을 고려할 수 있습니다. 이 기사에서는 메모리 페이지 크기에 영향을 미치는 다음 두 가지 요소를 소개합니다.

페이지 크기가 너무 작으면 페이지 테이블 항목이 더 커져 검색 속도가 증가하고 주소 지정 중 TLB(번역 참조 버퍼)의 추가 오버헤드가 발생합니다.

과도한 페이지 크기는 메모리 공간을 낭비하고 메모리 조각화를 유발하며 메모리 활용도를 감소시킵니다.

지난 세기에는 메모리 페이지 크기를 설계할 때 위의 두 가지 요소가 충분히 고려되었으며, 마침내 4KB 메모리 페이지가 운영 체제의 가장 일반적인 페이지 크기로 선택되었습니다. 다음으로 이들이 운영 체제 성능에 미치는 영향을 자세히 소개하겠습니다.

페이지 테이블 항목 Linux에 가상 메모리가 필요한 이유 기사에서 Linux의 가상 메모리를 소개했습니다. 각 프로세스에서 볼 수 있는 것은 독립적인 가상 메모리 공간입니다. 가상 메모리 공간은 여전히 ​​논리적인 개념일 뿐입니다. 즉, 가상 메모리에서 실제 메모리로 변환하려면 각 프로세스가 보유하는 페이지 테이블을 사용해야 합니다.

64비트 운영 체제에서 128TiB 가상 메모리의 매핑된 데이터를 저장하기 위해 Linux는 2.6.10에서 가상 주소 변환을 지원하는 4계층 페이지 테이블을 도입했으며, 5계층 페이지 테이블 구조가 도입되었습니다. 4.11에서는 향후 64비트 가상 주소를 지원하기 위해 더 많은 페이지 테이블 구조 계층이 도입될 수도 있습니다.

그림 2 – 4계층 페이지 테이블 구조

위와 같이 4레벨 페이지 테이블 구조에서 운영체제는 가장 낮은 12비트를 페이지 오프셋으로 사용하고, 나머지 36비트는 4개의 그룹으로 나누어 이전 레벨에서 현재 레벨의 인덱스를 나타냅니다. 모든 가상 주소는 위에서 언급한 다중 레이어 페이지 테이블을 사용하여 해당 물리적 ​​주소를 찾을 수 있습니다.

운영 체제의 가상 주소 공간의 크기는 고정되어 있기 때문에 전체 가상 주소 공간은 동일한 크기의 N개의 메모리 페이지로 균등하게 나누어지므로 메모리 페이지의 크기에 따라 궁극적으로 계층 구조와 페이지 테이블 항목이 결정됩니다. 특히, 가상 페이지 크기가 작을수록 단일 프로세스에 더 많은 페이지 테이블 항목과 가상 페이지가 있습니다.

PagesCount=가상 메모리 ¼ 페이지 크기

현재 가상 페이지 크기가 4096바이트이므로 가상 주소 끝의 12비트가 가상 페이지의 주소를 나타낼 수 있습니다. 가상 페이지의 크기를 512바이트로 줄이면 원래 4레벨 페이지가 됩니다. 테이블 구조 또는 5레벨 페이지 테이블 구조는 5~6개의 레이어가 되며, 이는 메모리 액세스의 추가 오버헤드를 증가시킬 뿐만 아니라 각 프로세스의 페이지 테이블 항목이 차지하는 메모리 크기도 증가시킵니다.

조각화

메모리 매핑 장치는 메모리 페이지 수준에서 작동하기 때문에 운영 체제는 메모리 할당의 가장 작은 단위를 가상 페이지로 간주합니다. 사용자 프로그램이 1바이트의 메모리만 적용하더라도 운영체제는 이에 대한 가상 페이지를 적용하게 되는데, 아래 그림과 같이 메모리 페이지의 크기가 24KB라면 1바이트의 메모리를 적용하게 된다. 공간의 ~99.9939%를 낭비합니다.

그림 3 – 대용량 메모리의 조각화

메모리 페이지 크기가 증가함에 따라 메모리 조각화는 점점 더 심각해집니다. 작은 메모리 페이지는 메모리 공간의 메모리 조각화를 줄이고 메모리 활용도를 향상시킵니다. 지난 세기에는 메모리 자원이 오늘날만큼 풍부하지 않았습니다. 대부분의 경우 메모리는 프로그램 실행을 제한하는 자원이 아닙니다. 대부분의 온라인 서비스에는 더 많은 메모리가 아닌 더 많은 CPU가 필요합니다. 그러나 기억은 실제로 지난 세기에는 희소한 자원이었기 때문에 희소한 자원의 활용도를 높이는 것은 우리가 고려해야 할 사항입니다.

그림 4 – 메모리 가격

1980년대와 1990년대의 메모리스틱은 512KB나 2MB에 불과했고 가격도 터무니없이 비쌌습니다. 하지만 오늘날에는 수 GB의 메모리가 매우 보편화되어 있기 때문에 메모리 활용도가 여전히 중요하지만 오늘날에는 메모리 가격이 크게 떨어졌습니다. , 조각화된 메모리는 더 이상 해결해야 할 주요 문제가 아닙니다.

메모리 사용률 외에도 더 큰 메모리 페이지는 Linux의 쓰기 중 복사 메커니즘으로 인해 여러 프로세스가 동일한 메모리를 공유할 때 프로세스 중 하나가 변경되면 메모리 복사의 추가 오버헤드도 증가시킵니다. 이때 운영 체제의 메모리 페이지가 작을수록 쓰기 중 복사로 인한 추가 오버헤드가 줄어듭니다.

요약

위에서 언급했듯이 4KB 메모리 페이지는 지난 세기에 결정된 기본 설정이며 오늘날의 관점에서 볼 때 이는 아마도 잘못된 선택일 것입니다. arm64 및 ia64와 같은 아키텍처는 이미 8KB, 16KB의 메모리 페이지 및 기타 크기를 지원할 수 있습니다. 메모리 가격이 점점 낮아지고 시스템 메모리가 점점 커지면 운영 체제에 더 큰 메모리가 더 나은 선택이 될 수 있습니다. 페이지 크기 요소에 대한 두 가지 결정을 검토해 보겠습니다.

페이지 크기가 너무 작으면 페이지 테이블 항목이 더 커지게 되어 TLB(Translation Lookaside buffer) 검색 속도가 증가하고 주소 지정 중 추가 오버헤드가 발생하지만 프로그램의 메모리 조각화가 줄어들고 메모리 활용도가 향상됩니다.
• 과도한 페이지 크기는 메모리 공간을 낭비하고, 메모리 조각화를 일으키고, 메모리 사용률을 감소시키지만, 프로세스의 페이지 테이블 항목과 TLB 주소 지정 시간을 줄일 수 있습니다.
마지막에는 상대적으로 개방적인 관련 질문을 살펴보겠습니다. 관심 있는 독자는 다음 질문에 대해 신중하게 생각해 볼 수 있습니다.
• Linux의 섹터, 블록, 페이지 간의 차이점과 연결은 무엇입니까?

Linux에서는 블록 크기가 어떻게 결정되나요? 일반적인 크기는 무엇입니까?

위 내용은 Linux 시스템의 기본 페이지 크기가 4KB인 이유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!