[unix] 시스템 메모리에서 … 구체적으로`tmpfs,“shm,`및`hugepages…`의 차이점

tmpfs와 shm과의 차이점은 없습니다. tmpfs는 shm의 새로운 이름입니다. shm은 SHaredMemory를 나타냅니다.

Linux tmpfs를 참조하십시오 .

tmpfs가 오늘날에도 사용되는 주된 이유는 젠투 박스의 / etc / fstab에있는 주석입니다. BTW Chromium은 라인이 누락되어 빌드되지 않습니다.

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0

리눅스 커널 문서 에서 나온

인용 :

tmpfs는 다음과 같은 용도로 사용됩니다.

1) 커널 내부 마운트는 항상 보이지 않습니다
. 공유 익명 맵핑 및 SYSV 공유
메모리에 사용됩니다.

이 마운트는 CONFIG_TMPFS에 의존하지 않습니다. CONFIG_TMPFS를 설정하지 않으면 tmpfs의 사용자가 볼 수있는 부분이 빌드되지 않습니다. 그러나 내부
메커니즘은 항상 존재합니다.

2) glibc 2.2 이상에서는
POSIX 공유 메모리 (shm_open, shm_unlink)의 tmpfs가 / dev / shm에 마운트 될 것으로 예상 합니다.
/ etc / fstab에 다음 줄을 추가하면이 문제를 해결 해야합니다.

tmpfs / dev / shm tmpfs 기본값은 0 0

필요한 경우 tmpfs를 마운트하려는 디렉토리를 작성하십시오.

SYSV 공유 메모리 에는 이 마운트가 필요 하지 않습니다 . 이를 위해 내부
마운트가 사용됩니다. 2.3 커널 버전
에서는 SYSV
공유 메모리 를 사용하기 위해 tmpfs (shm fs)의 선행 버전 을 마운트해야했습니다.

3) 나를 포함한 일부 사람들
은 / tmp 및 / var / tmp에 마운트하는 것이 매우 편리 하고 큰 스왑 파티션을 가지고 있다고 생각합니다. 이제
tmpfs 파일의 루프 마운트가 작동하므로 대부분의
배포에서 제공되는 mkinitrd 는 tmpfs / tmp로 성공해야합니다.

4) 그리고 아마 더 많이 몰라 🙂

tmpfs에는 크기 조정을위한 세 가지 마운트 옵션이 있습니다.

size : 이 tmpfs 인스턴스에 할당 된 바이트 제한. 기본값은 스왑이없는 실제 RAM의 절반입니다. tmpfs 인스턴스의 크기를 초과하면 OOM 핸들러가 해당 메모리를 해제 할 수 없으므로 시스템 교착 상태가 발생합니다.
nr_blocks : 크기와 동일하지만 PAGE_CACHE_SIZE 블록입니다.
nr_inodes : 이 인스턴스의 최대 inode 수. 기본값은 실제 RAM 페이지 수의 절반이거나 (memem이있는 시스템의 경우) lowmem RAM 페이지 수 중 낮은 쪽입니다.

투명한 Hugepage 커널 문서에서 :

Transparent Hugepage Support는 사용되지 않은 모든 메모리를 캐시 또는 다른 이동 가능 (또는 이동 불가능한 엔티티)으로 사용할 수 있도록함으로써 hugetlbfs의 예약 접근 방식과 비교할 때 사용 가능한 메모리의 유용성을 최대화합니다. 사용자 페이지에서 대량의 페이지 할당 실패가 눈에 띄지 않도록 예약 할 필요는 없습니다. 페이징 및 기타 모든 고급 VM 기능을 거대한 페이지에서 사용할 수 있습니다. 응용 프로그램이이를 활용할 수 있도록 수정하지 않아도됩니다.

그러나 모든 malloc (4k)에 대해 mmap 시스템 호출을 피하기 위해 최적화 된 것과 같이이 기능을 활용하도록 애플리케이션을 추가로 최적화 할 수 있습니다. 사용자 영역을 최적화하는 것은 필수 사항이 아니며 khugepaged는 이미 많은 양의 메모리를 다루는 거대한 페이지를 인식하지 못하는 응용 프로그램의 경우에도 오래 지속되는 페이지 할당을 처리 할 수 ​​있습니다.

---

몇 가지 계산을 한 후 새로운 설명 :

HugePage 크기 : 2MB
HugePages 사용 : 없음 / 꺼짐 (모두 0으로 표시되지만 위의 2Mb에 따라 활성화 됨).
DirectMap4k : 8.03Gb
DirectMap2M : 16.5Gb
DirectMap1G : 2Gb

THS의 최적화와 관련하여 위의 단락을 사용하면 4K의 malloc을 사용하여 작동하는 응용 프로그램이 16.5Gb의 malloc을 사용하는 응용 프로그램에서 8Gb의 메모리를 사용하고있는 것으로 보입니다. 2M의 malloc을 사용하는 응용 프로그램은 2M 섹션을 커널로 오프로드하여 HugePage Support를 모방합니다. malloc이 커널에 의해 릴리스되면 메모리가 시스템에 릴리스되는 반면 hugepage를 사용하여 tmpfs를 마운트하면 시스템이 재부팅 될 때까지 완전히 정리되지 않습니다. 마지막으로, 쉬운 것은 1Gb의 malloc을 요청한 2 개의 프로그램을 열고 실행하는 것입니다.

malloc을 모르는 독자라면 C의 표준 구조는 메모리 할당을 의미합니다. 이러한 계산은 DirectMapping과 THS 간의 OP의 상관 관계가 올바른지 증명합니다. 또한 HUGEPAGE 만 fs를 마운트하면 2MB 만 증가하는 반면 THS를 사용하여 시스템을 메모리로 관리하면 대부분 4k 블록으로 발생합니다. 이는 모든 malloc 호출로 인해 시스템이 2044k를 절약한다는 의미입니다 (2048-4). ) 다른 프로세스를 사용할 수 있습니다.

---

답변