☰

시스템 메모리... 특히 "tmpfs", "shm" 및 "hugepages..."의 차이점

tag-icon • tag-icon linux filesystems memory tmpfs shared-memory
시스템 메모리... 특히 "tmpfs", "shm" 및 "hugepages..."의 차이점

최근 리눅스 커널 메모리 기반의 다양한 파일 시스템에 대해 궁금해졌습니다.

Note:내가 생각하는 한, 다음 질문은 제목에서 묻는 질문을 더 잘 이해하는 것과 비교할 때 다소 선택 사항으로 간주되어야 합니다. 아래에 질문하는 이유는 답변을 드리는 것이 차이점을 이해하는 데 더 도움이 될 것이라고 생각하기 때문입니다. 하지만 제가 이해한 범위가 정말 제한되어 있기 때문에 다른 사람들이 더 잘 알 수도 있습니다. 제목에 언급된 세 가지 파일 시스템 간의 차이점에 대한 이해를 높이는 데 도움이 되는 모든 답변을 받아들일 준비가 되어 있습니다.

궁극적으로 사용 가능한 파일 시스템을 마운트하고 싶다고 생각합니다.hugepages,약간의 가벼운 연구(그리고 더 가벼운 땜질)로 인해 나는 믿게 되었습니다.rewritable hugepage mount옵션이 아닙니다. 내가 잘못? 여기서 메커니즘은 무엇입니까?

또한 약hugepages:

     uname -a
3.13.3-1-MANJARO \
#1 SMP PREEMPT \
x86_64 GNU/Linux

    tail -n8 /proc/meminfo
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     8223772 kB
DirectMap2M:    16924672 kB
DirectMap1G:     2097152 kB

(여기에서 전체 텍스트 버전을 볼 수 있습니다./proc/메모리 정보그리고/proc/cpu 정보)

위와 같은 상황에서는 무슨 일이 벌어지고 있는 걸까요? 내가 배정했나요?hugepages?사이에 차이가 있나요DirectMap메모리 페이지와hugepages?

고쳐 쓰다@Gilles로부터 약간의 재촉을 받은 후 위에 4줄을 더 추가했는데 차이점이 있는 것 같습니다. 비록 들어본 적은 없지만DirectMap그거 뽑기 전에tail어제...아마도DMI또는 다른 것?

조금만 더...

아무런 성공도 없이hugepages노력을 기울이고 모든 이미지 파일의 하드 드라이브 백업을 가정합니다. 루프 설치로 인한 위험은 무엇입니까?tmpfs?내 파일 시스템은swapped최악의 시나리오는 무엇입니까? 알겠어요tmpfs마운트된 파일 시스템 캐시 - 메모리 부족으로 인해 마운트된 루프 파일이 스트레스를 받습니까? 이를 방지하기 위해 취할 수 있는 완화 조치가 있습니까?

마지막으로 - 정확히 무엇입니까?shm,그래도? 그것은 어떻게 다르거나 포함됩니까?hugepages또는tmpfs?

답변1

tmpfs와 shm 사이에는 차이가 없습니다. tmpfs는 shm의 새로운 이름입니다. shm은 공유 메모리를 나타냅니다.

바라보다:Linux 임시 파일 시스템.

오늘 tmpfs를 사용하는 주된 이유는 내 젠투 컴퓨터의 /etc/fstab에 있는 이 주석 때문입니다. 그런데 다음 줄이 없으면 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

~에서Linux 커널 파일 시스템 문서

인용하다:

tmpfs의 용도는 다음과 같습니다.

  1. 커널 내부에는 보이지도 않는 마운트가 항상 존재합니다
    . 이는 공유 익명 매핑 및 SYSV 공유
    메모리 에 사용됩니다 .

    이 마운트는 CONFIG_TMPFS에 의존하지 않습니다. CONFIG_TMPFS가 설정되지 않은 경우 tmpfs의 사용자에게 표시되는 부분은 빌드되지 않습니다. 그러나 내부
    메커니즘은 항상 존재합니다.


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

tmpfs /dev/shm tmpfs 기본값 0 0

필요한 경우 tmpfs가 마운트될 디렉터리를 생성하는 것을 잊지 마십시오.

이 마운트는아니요SYSV 공유 메모리에 필요합니다. 내부
마운트는 이러한 목적으로 사용됩니다. (2.3 커널 버전에서는 SYSV 공유 메모리를
사용하기 위해서는 tmpfs의 전신(shm fs)을 마운트해야 함 )


  1. 나를 포함한 일부 사람들은 이를 /tmp 및 /var/tmp에 설치하고 큰 스왑 파티션을 갖는 것이 편리하다고 생각합니다 . 이제
    tmpfs 파일의 순환 마운트가 작동하므로
    대부분의 배포판과 함께 제공되는 mkinitrd는 tmpfs /tmp를 성공적으로 사용할 수 있습니다.

  2. 제가 모르는 게 더 많을 것 같아요 :-)

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

크기: 이 tmpfs 인스턴스에 할당된 바이트 수에 대한 제한입니다. 기본값은 물리적 RAM의 절반이며 스왑이 없습니다. tmpfs 인스턴스가 너무 크면 OOM 핸들러가 메모리를 해제할 수 없기 때문에 시스템이 교착 상태에 빠지게 됩니다.
블록 수:크기와 동일하지만 PAGE_CACHE_SIZE 단위입니다.
nr_inodes:이 인스턴스의 최대 inode 수입니다. 기본값은 물리적 RAM 페이지 수의 절반 또는 (highmem이 있는 시스템에서) lowmem RAM 페이지 수의 절반 중 더 작은 값입니다.

~에서투명한 거대한 페이지 커널 문서:

hugetlbfs의 예약 접근 방식과 비교하여 투명한 hugepage 지원은 사용되지 않은 모든 메모리를 캐시 또는 기타 제거 가능한(또는 제거 불가능한 엔터티)로 사용할 수 있도록 허용하여 사용 가능한 메모리의 유용성을 극대화합니다. 사용자 공간이 hugepage 할당 실패를 인지하지 못하도록 예약할 필요는 없습니다. 이를 통해 대형 페이지에서 페이징 및 기타 모든 고급 VM 기능을 사용할 수 있습니다. 이를 활용하기 위해 애플리케이션을 수정할 필요가 없습니다.

그러나 이 기능을 활용하도록 애플리케이션을 더욱 최적화할 수 있습니다. 예를 들어 이전에는 malloc(4k)당 많은 수의 mmap 시스템 호출을 방지하도록 최적화되었습니다. 현재로서는 사용자 공간 최적화가 필수는 아니며, khugepaged는 대용량 메모리를 처리하는 hugepage 인식 애플리케이션의 경우에도 이미 장기 페이지 할당을 처리할 수 있습니다.

몇 가지 계산을 수행한 후 새 댓글:

HugePage 크기: 2MB
사용된 HugePages: 없음/끄기, 모두 0으로 표시되지만 위의 2Mb에 따라 활성화됩니다.
DirectMap4k: 8.03Gb
DirectMap2M: 16.5Gb
DirectMap1G: 2Gb

THS의 최적화에 대한 위의 단락을 사용하면 4k의 malloc 작업을 사용하는 애플리케이션에서 8Gb의 메모리를 사용하는 반면, 2M의 malloc을 사용하는 애플리케이션은 16.5Gb를 요청한 것으로 보입니다. 2M malloc을 사용하는 애플리케이션은 2M 부분을 커널로 오프로드하여 HugePage 지원을 에뮬레이트합니다. 커널에 의해 malloc이 해제되면 메모리가 시스템에 해제되는 반면, 대용량 페이지로 tmpfs를 마운트하면 시스템이 재부팅될 때까지 전체 정리가 이루어지지 않기 때문에 이는 선호되는 방법입니다. 마지막으로 가장 간단한 것은 2개의 프로그램이 열려 있고 실행 중이며 1GB의 malloc을 요청하는 것입니다.

모르는 독자를 위해 설명하자면, malloc은 메모리 할당을 나타내는 C 언어의 표준 구조입니다. 이러한 계산은 DirectMapping과 THS 간의 OP 상관관계가 아마도 정확할 것임을 증명합니다. 또한 HUGEPAGE ONLY fs를 설치하면 2MB의 증분 이득만 얻을 수 있는 반면, 시스템에서 THS를 사용하여 메모리를 관리하는 것은 대부분 4k 블록에서 발생합니다. 즉, 각 malloc 호출은 사용을 위해 메모리 관리(2048 - 4) 측면에서 시스템 2044k를 절약한다는 의미입니다. 다른 프로세스에 의해.

답변2

"DirectMap" 문제를 해결하려면 커널이물리적 메모리의 선형("직접") 매핑, 각 사용자 프로세스에 할당된 가상 맵과 별개입니다.

커널은 TLB 압력을 줄이기 위해 이 매핑에 가능한 한 큰 페이지를 사용합니다.

DirectMap1G는 CPU가 1Gb 페이지(바르셀로나 이상, 일부 가상 환경에서는 이를 비활성화함)를 지원하는 경우 표시되며 커널에서 활성화된 경우 기본값은 2.6.29+입니다.

답변3

shm및 사이에는 차이가 없습니다 tmpfs(실제로는 tmpfs이전의 새 이름일 뿐입니다 shmfs). 커널 대용량 페이지에서 공간을 할당하고 몇 가지 추가 구성이 필요한 기반 파일 시스템 hugetlbfs입니다 tmpfs(사용 방법문서/vm/hugetlbpage.txt).

관련 정보