메모리 페이지 크기가 2의 거듭 제곱이라고 가정하는 것이 안전합니까?

Question

현재 메모리 페이지 크기 (sysconf(_SC_PAGESIZE)에서 반환)를 사용하는 휴대용 C 프로그램을 작성 중입니다. 나는 페이지 크기가 비트 연산을 사용하는 효율적인 관리를 가능하게하는 2의 거듭 제곱이라는 것을 가장 잘 압니다. 그래도 어디서나이 보증을 찾지 못했습니다. 그렇다면 페이지 크기가 2의 힘이라고 가정하는 것이 얼마나 안전할까요? 이 조건을 만족시키지 못하는 아키텍처의 예가 있습니까?

Answer 1

페이지 크기가 2의 거듭 제곱이어야한다는 명시적인 설명을 찾을 수는 없지만 매우 합리적인 가정이라고 생각합니다. POSIX의 "정렬"개념 (posix_memalign 참조)은 임의의 약수가 아니라 2의 제곱으로 정의됩니다. 구체적으로 정렬 인수는 sizeof(void*)의 배수의 배수 여야합니다. 이 인터페이스로 페이지 정렬 메모리를 얻으십시오. 그 외에도 모든 실제 아키텍처는 두 페이지의 크기를 사용하며이를 변경하는 합리적인 근거가 없습니다. 하드웨어에서 비용이 많이 드는 것은 그 밖의 것입니다.

Answer 2

1) Linux 커널의 페이지 크기 계산을 통해 보장됩니다. 이것은 공식적인 표준이라는 의미에서 보증은 아니지만, 이미 언급 된 모든 이유로이 접근법이 바뀔 것 같지 않습니다. /usr/src/kernels/<your_kernel>/include/asm-generic/page.h에서

: 당신이 볼 수 있듯이

#define PAGE_SHIFT  12 
#ifdef __ASSEMBLY__ 
#define PAGE_SIZE  (1 << PAGE_SHIFT) 
#else 
#define PAGE_SIZE  (1UL << PAGE_SHIFT) 
#endif 

는 페이지 크기는 실제로 항상 두 가지의 힘이 될 것입니다, 따라서 변화의 관점에서 정의된다. 이 코드는 일반 아키텍처의 경우에 사용되며 특정 아키텍처에서는 PAGE_SHIFT에 대해 다른 값을 정의합니다.

2) 실용적인 측면에서 터미널에 getconf PAGESIZE을 입력하여 getconf 프로그램을 통해 페이지 크기를 얻을 수 있습니다. 이것은 결코 사용되지 않는 백업 케이스를 코딩하는 것보다 훨씬 쉬운 빠른 컴파일 타임 검사를 생성하는 데 사용될 수 있습니다.

3) 페이지 크기는 MMU에 의해 결정됩니다. 따라서 공식적인 표준에 가장 가까이 다가 가려면 다양한 제조업체의 프로세서 설명서가 필요합니다. 예를 들어, 인텔 소프트웨어 개발자 설명서의 볼륨 3A에서 표 4-1 인텔 프로세서의 페이징 모드와 페이지 크기의 완전한 목록 제공 :

4) 내가 말할 수를 그 모든 주요 프로세서 아키텍처 2의 제곱 인 페이지 크기를 사용합니다.

5) 실제 메모리 공간의 단편화 - 실제로 그렇지 않은 경우 큰 문제가 있습니다. 페이지와 페이지 프레임 크기는 동일해야하므로, 페이지 크기가 두 배가 아닌 경우 페이지 프레임이 두 배가됩니다. 페이지 프레임 크기가 3000이고 (예를 들어 간단히하기 위해) 전체 페이지 프레임이 32 개라고 가정 해 보겠습니다. 따라서 물리적 주소는 17 비트 길이 - 페이지 프레임을 선택하는 데 5 비트 및 3000 바이트를 주소 지정하는 12 비트입니다.

00000 0000 0000 0000 
\___/ \____________/ 
    |    \ 
(page frame) (page offset) 

페이지의 사이즈 (페이지 프레임 크기)의 2의 거듭 제곱 같으면

후 00000 0000 0000 0000에서 11111 1111 1111 1111되는 전체 물리 메모리 공간은 유효 주소이다. 페이지 프레임 크기가 3000 인 경우 XXXXX 1011 1011 0111 (마지막 유효한 주소)부터 XXXXX 1111 1111 1111까지 실제 주소 공간에 차이가 있습니다. 그러한 시스템을 사용할 수 없다는 말은 아니지만 생각할 이유가없는 끔찍한 복잡성을 더할 수 있습니다.