우리는 16KB 가상 메모리 페이지 크기의 이점을 누릴 수 있는 CPU를 설계하고 있습니다(이로 인해 캐시 액세스의 전력 효율성이 낮아지고 대상 작업 부하에 대한 성능이 향상되며 메모리 조각화는 문제가 되지 않습니다). 표준 페이지 크기는 4KB입니다. 커널 소스 코드에 기본 페이지 크기를 16KB로 구성하는 쉬운 방법이 있습니까? 아니면 4KB에서 16KB로 변경하려면 커널 소스 코드를 수정해야 합니까? 파일 시스템의 경우 가상 메모리 페이지 크기가 16KB인 경우 예상치 못한 부작용은 무엇입니까?
Linux 커널에 대한 더 깊은 이해를 제공하는 URL이 있다면 좋을 것입니다.
감사해요:-)
답변1
예, Linux 커널은 4KB 이외의 페이지 크기를 지원하며 어떤 경우에는 기본적으로 이러한 페이지 크기를 사용합니다.
x86_64 아키텍처에서는 4KB만 지원됩니다(AFAIK). 이것이 이 칩이 할 수 있는 유일한 작업이기 때문입니다.
예를 들어 ppc64 아키텍처는 4KB 페이지를 사용하는 커널 컴파일 타임 구성이 있지만 기본적으로 64KB 페이지로 설정됩니다(64KB 페이지보다 테스트가 덜 되었기 때문에 권장되지 않을 수 있음).
ARM(aarch64 플랫폼)의 경우 커널이 4KB, 16KB 및 64KB 페이지 크기를 지원한다고 생각합니다. Linux를 실행하는 ARM에서 이러한 페이지 크기를 본 적이 있기 때문입니다. (나는 이것들이 모두 업스트림 커널에서 나온 것이라고 믿습니다.)
"우리는 CPU를 설계하고 있습니다"라고 말하고 커널 소스 코드 수정에 대해 이야기합니다. 음, 새로운 아키텍처라면 페이지 크기 지원을 포함하여 이에 대한 지원을 커널에 추가해야 합니다! 기존 아키텍처(예: aarch64)의 구현인 경우 기존 지원을 사용할 수 있지만 이를 지원하려면 커널에 CPU 관련 항목을 추가해야 할 수도 있습니다.
파일 시스템의 경우 파일 시스템의 블록 크기가 페이지 크기와 일치할 필요는 없습니다. 페이지 크기가 16KB 또는 64KB인 시스템에서는 기본 블록 크기가 4KB인 ext4 형식을 사용할 수 있습니다.
이 두 가지가 서로 관련되는 경향이 있는 곳은 파일 시스템을 읽고 쓸 때 페이지 캐시를 우회하기 위해 O_DIRECT를 사용하는 것입니다. 그러나 이는 여전히 작동하며 최신 커널에서는 일반적으로 512바이트 경계에서만 정렬이 필요합니다.
즉, 페이지 크기와 파일 시스템 블록 크기는 어떤 방식으로든 일치할 필요가 없습니다.