☰

실제적인 문제

tag-icon • tag-icon memory virtual-memory mmap huge-pages
실제적인 문제

이사 공지

방금 이 질문(약간 수정됨)을 StackOverflow 질문(교차 게시에 대한 강력한 반대 때문에 삭제함)에서 옮겼는데 아직 답변이 제공되지 않았으며 여기에 더 적합할 수 있습니다.

StackOverflow 질문에는 두 가지 의견(답변 없음)이 있습니다. 다음은 이러한 의견에 대한 간략한 요약입니다(이를 이해하려면 실제 질문을 읽어야 할 수도 있습니다).

  • 파일 시스템 접근 방식을 libhugetlbfs사용하면 다양한 작업을 수행할 수 있습니다.
    • 그것은 저에게 별로 설득력이 없습니다. 제가 응용 프로그램 프로그래머로서 파일 시스템을 통하지 않고 거대한 페이지를 할당할 수 있다면 괜찮습니다. 그렇죠 libhugetlbfs?
  • 파일 시스템을 통해 누가 대용량 페이지를 할당할 수 있는지에 대한 권한을 설정할 수 있습니다.
    • 물론 가능하지만 파일 시스템을 통과할 필요는 없습니다. 누구든지 그렇게 할 수 있다면 mmap(…, MAP_HUGETLB, …), 파일 시스템 수준에서 접근이 거부된 사람이라면 누구나 이 방식으로 거대한 페이지를 모두 소진할 수 있습니다 mmap.

실제적인 문제

저는 현재 Linux에서 거대한 페이지에 메모리를 할당하는 다양한 방법을 모색하고 있습니다. 왠지 HugeTLB "파일 시스템"의 개념을 이해할 수 없습니다. 나는 투명한 거대한 페이지에 대해 말하는 것이 아닙니다. 이것은 완전히 다른 짐승입니다.

전통적인 방식

전통적인 견해(예:데비안 위키또는커널 문서) 다음과 같은 것 같습니다.

  • 커널 구성이 올바르게 설정되었는지 확인하세요.
  • 다양한 커널 매개변수를 올바르게 설정
  • 예를 들어 특수 파일 시스템( hugetlbfs)을 임의의 디렉터리에 마운트하는 경우 /dev/hugepages/(Fedora에서는 기본값인 것 같습니다...)
  • mmap()해당 디렉토리에 있는 파일을 주소 공간으로 복사합니다. 즉, 다음과 같습니다.
int fd = open("/dev/hugepages/myfile, O_CREAT | O_RDWR, 0755);
void * addr = mmap(0, 10*1024*1024, (PROT_READ | PROT_WRITE), MAP_SHARED, fd, 0);

addr...이 두 호출이 성공하면 5개의 2MB 대용량 페이지에 할당된 10MB의 메모리를 가리켜 야 합니다 . 좋아요

간단한 방법

그런데 너무 복잡해 보이죠?

적어도 Linux 5.15에서는 전체 파일 시스템이 완전히 불필요한 것처럼 보입니다. 방금 이것을 시도했습니다.

  • HugeTLBfs로 구성된 커널
  • 커널 매개변수가 올바르게 설정되었습니다(예: vm.nr_hugepages > 0).
  • hugetlbfs어디에도 설치되지 않은

그런 다음 익명의 추억을 만드십시오 mmap.

void *addr = mmap(0, 10*1024*1024, (PROT_READ | PROT_WRITE),
                  (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB), 0, 0);

이렇게 하면 거대한 페이지에 10MB의 메모리가 할당됩니다(적어도 페이지 테이블의 플래그를 해석할 때 실패하지 않는 경우).

왜 파일 시스템인가?

그래서 내 질문은: 왜 파일 시스템인가? 다양한 가이드에서 제안하는 것처럼 파일 시스템을 통과하는 것이 정말 "필요"합니까? 위의 시도는 단지 운이 좋았을 뿐입니다. 파일 시스템 접근 방식에 다른 이점이 있습니까(거대한 총처럼 보이는 RAM의 일부를 나타내는 파일을 갖는 것 외에...)? 아니면 MAP_ANONYMOUS | MAP_HUGETLB이전에 허용되지 않았던 시대의 잔재일까요?

관련 정보