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


16

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

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 / meminfo/ proc / cpuinfo 의 전체 텍스트 버전은 다음과 같습니다. )

위의 내용은 무엇입니까? 이미 할당하고 hugepages?있습니까 DirectMap메모리 페이지와 차이가 있습니까?hugepages?

업데이트 @Gilles에서 찔러 조금 후에, 나는 위의 4 개 라인을 추가했습니다 내가 들어 본 적이 거라고하지만 차이가 있어야한다 보인다 DirectMap그 당겨 전에 tail어제 ... 어쩌면 DMI또는 뭔가를?

조금만 더 ...

hugepages노력으로 성공하지 못하고 이미지 파일의 하드 디스크 백업을 가정 할 때 루프를 마운트 할 때의 위험은 무엇 입니까? tmpfs?파일 시스템이 swapped최악의 시나리오입니까? tmpfs마운트 된 파일 시스템 캐시를 이해합니다. 마운트 된 루프 파일에 메모리가 부족할 수 있습니까? 이것을 피하기 위해 취할 수있는 완화 조치가 있습니까?

마지막-정확히 무엇 shm,입니까? 어떻게이 다를 또는 포함 않습니다 중 하나 hugepages또는tmpfs?


1
/proc/meminfo포함 된 이전 줄은 HugePage어떻습니까 (또는 커널 버전에 없는가)? 이것은 어떤 아키텍처입니까 (x86_64라고 가정합니다)?
Gilles 'SO- 악마 그만해'

추가하겠습니다. 나는 그것이 너무 길다는 것에 대해 걱정했다.
mikeserv

@Gilles-위의 일반 텍스트에 연결했습니다. 나는 그것이 좋기를 바랍니다. 물어 주셔서 감사합니다-처음에 포함해야합니다-어떻게 그것을 놓쳤는 지 모르겠습니다.
mikeserv

답변:


13

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). ) 다른 프로세스를 사용할 수 있습니다.


2
THS가 내 DirectMap 입니까?
mikeserv

내가 DirectMapping을 googled하고 tmpfs 등과 관련된 것을 찾지 못했을 때 대답 할 수 없다는 것. 내가 찾을 수있는 유일한 것은 Linux의 풍미에서 실행되는 Oracle 데이터베이스에 대해 HugeMem 지원을 구성하는 방법이었습니다. 즉 THS 대신 HugePages를 사용하고 있음을 의미합니다 나는 언급했다. 2.6 브랜치의 모든 커널은 THS를 지원합니다. 직감으로, 위의 새로운 의견을 참조하십시오.
eyoung100

그래, 나도 거의 나타나지 않았다. HP, THP에서 약간의 독서를했습니다. 나는 당신의 의견에 꽤 흥미가 있습니다. 이건 정말 형성되고있어 이 마지막 부분 (HP 만 해당)을 거대한 페이지 마운트 위에 읽기 / 쓰기 파일 시스템을 마운트 할 수 있다는 의미로 해석해야 합니까? 거대한 페이지 마운트에서 루프 마운트 된 이미지 파일처럼? 쓰기 가능?
mikeserv

예, 그리고 올바르게 마운트하면 쓰기 가능하지만 다음 사항에 유의하십시오. 1. 마운트 한 후에 정리를 담당합니다. 캐릭터 : 안녕하세요, 제 이름은 Mike입니다. 각 문자가 1k라고 가정하면 해당 파일은 23k로 저장됩니다. Hugepage가 2MB를 주면서 2025k를 낭비했습니다. 그 낭비적인 행동은 메모리 관리가 커널에 내장 된 이유입니다. 또한 kernel32와 같은 래퍼 DLL이 필요하지 않습니다.
eyoung100

마지막으로 3. 재부팅 또는 충돌시 마운트가 손실됩니다.
eyoung100

4

"DirectMap"문제를 해결하기 위해 : 커널에는 각 사용자 프로세스에 할당 된 가상 매핑과 별개 로 물리적 메모리에 대한 선형 ( "직접") 매핑이 있습니다.

커널은이 매핑에 가능한 가장 큰 페이지를 사용하여 TLB 압력을 줄입니다.

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


3

shm와 사이에는 차이가 없습니다 tmpfs(실제로 tmpfs전자의 새로운 이름 일뿐입니다 shmfs). hugetlbfsA는 tmpfs할당 커널 큰 페이지에서의 공간과 몇 가지 추가 구성이 여유가 필요로하는 기반 파일 시스템 (이 설명되어 있습니다 사용하는 방법 문서 / VM / hugetlbpage.txt ).


이것은 좋은 시도였으며 물론 그 문서를 읽었습니다. 또는 물론 아닐 수도 있습니다. 그러나 나는 100rep 현상금으로 이것을 내놓을 것이라고 생각하지만, 그렇게하기 전에, 당신이 이것을 확장 할 수 있다면 나는 그것을 당신에게 제공 할 것입니다. 지금까지 당신은 내 이해풍부하게 만들지 않았습니다. 나는 그 둘이 단지 동의어라는 것을 제외하고는 이미 대부분을 알고있었습니다. 어쨌든 내일 아침까지 더 나은 답변을 얻을 수 있다면 100rep 현상금은 당신의 것입니다. 특히 흥미로운 DirectMap것은 procfs man페이지 에서 전혀 언급이 없다는 것 입니다. 어떻게 오세요?
mikeserv

1
@ mikeserv-DirectMaps가 계산되는 기능을 보여주는이 차이점을 발견했습니다. lkml.org/lkml/2008/11/6/163
slm
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.