Linux DAX(직접 액세스) 세부정보

귀하의 예를 논의하기 전에 약간의 면책 조항이 있습니다. 이것은 현실의 단순화된 버전입니다. 제가 설명하지 않은 많은 특수 사례와 예외가 있지만, 무슨 일이 일어나고 있는지 이해하는 데는 충분할 것입니다...

---

블록 장치

당신을 혼란스럽게 하는 것은 "블록 장치"라는 용어를 오용하는 것입니다. 블록 장치는 일반적으로 HDD, CD, SSD입니다. 이름에서 알 수 있듯이 이러한 장치에는 개별 바이트를 읽거나 쓸 수 없으며 블록(보통 512바이트 크기)으로 써야 합니다.

블록 장치에는 장치 상태를 읽고 명령을 보내는 데 사용할 수 있는 프로세서 주소 공간에 매핑된 여러 레지스터와 작은 메모리 영역이 있습니다. 그러나 (일반적으로) 자신이 저장한 데이터에 대한 직접적인 액세스를 제공하지 않습니다. 이는 일반적으로 장치에 명령을 보내고 DMA 작업(읽기 또는 쓰기)이 완료되었음을 나타내는 하드웨어 인터럽트를 기다리는 방식으로 수행됩니다.

따라서 이러한 유형의 장치는 해당 작업에 DMA 작업 등이 포함되므로 주 메모리(DRAM)를 사용하지 않는 것이 다소 어렵습니다(불가능하지는 않지만). 이러한 경우 DAX가 수행하는 작업은 데이터 액세스와 관련된 오버헤드 중 일부를 제거하는 것뿐입니다.

DIMM 형식* NVM

그러나 최근에는 일부 DIMM 형식* NVM(비휘발성 메모리)이 시장에 출시되었습니다. 이러한 장치에는 액세스할 수 있도록 전체 내용이 프로세서 주소 공간에 매핑되어 있습니다.곧장저장 및 로드 명령어를 통해 프로세서에 의해. 커널은 이러한 장치가 액세스되고 있다는 사실을 알 필요조차 없습니다. 모든 의도와 목적을 위해 프로세스가 일반 DRAM 지원 메모리 페이지에 액세스하는 것처럼 보입니다.

*DIMM 형식은 예시일 뿐입니다. PCI와 같은 다른 기존 인터페이스도 이를 수행합니다.

혼란스러운 부분

여기에 혼란이 옵니다... 최근까지 "저장 장치"는 실제로 "블록 장치"의 동의어였습니다. Linux 커널은 이러한 새로운 NVM을 저장 장치/블록 장치로 인식하고 SSD와 마찬가지로 /dev에 항목을 생성하여 적절하게 처리합니다. (이러한 NVM 지원 장치 중 하나가 없는 경우 일반 DRAM의 특정 메모리 범위를 NVM으로 처리하도록 지정하여 이를 에뮬레이트할 수 있습니다.이봐이를 수행하는 방법에 대한 추가 정보. )

이러한 장치에 파일 시스템을 생성하면 일반 HDD를 사용하는 것처럼 작동합니다. 콘텐츠를 DRAM에 캐싱하여 성능을 향상시키려고 합니다. DAX 지원 파일 시스템이 수행하는 작업은 캐시 생성을 방지하는 것입니다. 이는 액세스 속도를 높이기 위한 것이지만 이러한 경우 성능이 저하될 수 있습니다.

---

커널 또는 해당 모듈이 DAX 지원 블록 장치의 DAX 지원 파일 시스템에 저장되어 있는 경우에도 여전히 RAM에 복사됩니다.

이 동작에 대한 확실한 이유를 찾을 수는 없지만 커널과 커널 모듈이 느린(DRAM보다 느린) 장치에서 실행되지 않고 해당 내용이 다음에서 실행되도록 보장하는 것은 보안 및 성능상의 이유인 것 같습니다. 커널 기간은 엉망이 되지 않습니다.

그러나 NVM 지원 메모리를 사용하여 NVM에서 직접 실행 파일을 실행하는 한 사용자 공간에 남아 있는 한 아무런 문제가 없습니다.

프로젝트를 살펴보세요Pmem.io인텔과아틀라스HP에서. 이러한 종류의 작업을 위해 특별히 만들어진 프로그래밍 인터페이스입니다.

---

이제 귀하의 예에 대해 :

# mount -t ramfs -o dax,size=8m ext2 /ramdisk
# mount
rootfs on / type rootfs (rw,size=59124k,nr_inodes=14781)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
ext2 on /ramdisk type ramfs (rw,relatime,dax,size=8m)
#

RAM 지원 EXT2 파일 시스템을 생성하지 않았습니다. 가상 이름이 ext2인 ramfs를 사용하여 RAM 지원 파일 시스템을 생성하고 있습니다. 다음과 같이 설치해도 아무런 차이가 없습니다.

# mount -t ramfs -o dax,size=8m winter_is_coming /ramdisk

.text 영역을 유지하지만 .data 영역의 복사본을 생성합니까?

어쨌든 exec()같은 방식으로 작동합니다. 이러한 페이지는 프로세스의 가상 주소 공간에 읽기 전용으로 매핑됩니다. 따라서 쓰기로 인해 페이지 폴트 인터럽트가 발생합니다. 이러한 페이지 폴트 처리는 다음과 같이 설명됩니다.mmap()MAP_PRIVATE쓰기 중 복사.

DAX의 경우 가상 페이지는 처음에 디바이스의 물리적 페이지에 매핑됩니다. 그러나 MAP_PRIVATE의 쓰기 페이지 오류는 페이지 데이터를 RAM의 새 페이지에 복사합니다. (그러면 프로세스의 맵이 그에 따라 업데이트되고 중단된 프로그램 명령이 다시 시작됩니다.)

DAX는 쓰기와 읽기를 모두 허용하는 XIP, 즉 MAP_SHARED 및 MAP_PRIVATE를 일반화한 것입니다. 예를 들어 MAP_SHARED는 데이터베이스 파일에 사용될 수 있습니다.

---

실제로 .text공유 라이브러리에 작성될 수도 있습니다. 위치 독립적 실행 파일이 아니고 자신에 대한 참조를 포함하는 라이브러리는 종속 라이브러리가 로드되는 주소를 기반으로 해당 참조를 업데이트해야 합니다. 이 과정을 "재배치"라고 합니다. 라이브러리는 libc와 같은 다른 라이브러리도 참조합니다. 이러한 참조를 업데이트하는 것을 "기호 확인"이라고 합니다.

커널 또는 해당 모듈이 DAX 지원 블록 장치의 DAX 지원 파일 시스템에 저장되어 있는 경우에도 여전히 RAM에 복사됩니다.

커널 모듈은 특별합니다. 또한 기호 확인이 필요합니다. 그러나 커널은 COW를 사용하지 않습니다. (더 일반적으로 해당 코드와 데이터 세그먼트는 요청 페이징을 사용하지 않습니다.) 커널 내부의 페이지 오류는 이를 처리하면 무한 재귀로 이어질 수 있으므로 치명적입니다! 따라서 DAX 이전에는 커널 모듈을 RAM에 완전히 복사해야 한다는 것이 분명했습니다. 커널 코드와 데이터 세그먼트는 더 작습니다. DAX가 구현되면 바이트 주소 지정이 가능한 스토리지가 있는 서버에서 수정해도 이점이 없습니다.

커널 자체는 역사적으로 압축되었으며 분명히 RAM으로 압축이 풀렸습니다.

즉, XIP는예지원됨압축되지 않은 커널의 경우. 이는 일반적으로 "임베디드" 시스템, 즉 매우 제한된 하드웨어에 사용됩니다. 이 시점에서는 로드 가능한 모듈을 사용하는 것에 비해 필요한 코드를 대부분 구축하는 것이 문제가 되지 않을 수 있습니다.