vNVML: An Efficient User Space Library for Virtualizing and Sharing Non-Volatile Memories

어떤 내용의 논문인가요? 👋

NVM을 가상화하고 공유하는 사용자 공간 라이브러리인 vNVML을 제안하여 여러 애플리케이션에서 공유할 수 있는 더 크고 빠른 바이트 주소 지정이 가능한 NVM에 관한 연구

NVM에 대한 바이트 수준 라이브러리 인터페이스인 vNVML 개발
NVM을 쓰기 로그와 쓰기 캐시로 사용하고 DRAM을 읽기 캐시로 사용
실제 워크로드로 평가하여 단일 O/S와 컨테이너와 같은 도커를 사용하는 경우 모두에서 애플리케이션이 NVM을 공유할 수 있음을 보여줌

Abstract (요약) 🕵🏻‍♂️

Abstract—The emerging non-volatile memory (NVM) has attractive characteristics such as DRAM-like, low-latency together with the non-volatility of storage devices. Recently, byteaddressable, memory bus-attached NVM has become available. This paper addresses the problem of combining a smaller, faster byte-addressable NVM with a larger, slower storage device, like SSD, to create the impression of a larger and faster byteaddressable NVM which can be shared across many applications. In this paper, we propose vNVML, a user space library for virtualizing and sharing NVM. vNVML provides for applications transaction like memory semantics that ensures write ordering and persistency guarantees across system failures. vNVML exploits DRAM for read caching, to enable improvements in performance and potentially to reduce the number of writes to NVM, extending the NVM lifetime. vNVML is implemented and evaluated with realistic workloads to show that our library allows applications to share NVM, both in a single O/S and when docker like containers are employed. The results from the evaluation show that vNVML incurs less than 10% overhead while providing the benefits of an expanded virtualized NVM space to the applications, allowing applications to safely share the virtual NVM.

이 논문을 읽어서 무엇을 배울 수 있는지 알려주세요! 🤔

💡 요약

abstract: 여러 애플리케이션에서 공유할 수 있는, 더 크고 빠른 바이트 주소 지정이 가능한 NVM을 구현할 수 있도록 NVM을 가상화하고 공유하는 사용자 공간 라이브러리인 vNVML을 소개한다. DRAM을 읽기 캐시로 사용하는 방법을 살펴보고, 특정 읽기에 대해 NVM을 우회하여 잠재적으로 쓰기 액세스 횟수를 줄이는 방법을 제안함.

introduction: NVM 기술은 DRAM에 필적하는 빠른 액세스 시간과 바이트 주소 지정 기능을 제공하여 기존 저장 장치와 휘발성 메모리를 대체할 수 있지만, 기존의 기술로는 NVM을 효율적으로 가상화하고 공유할 수 없다는 문제가 있다.

related works:

SPAN: 운영 체제 커널의 스왑 기능을 개선하여 NVM을 확장된 시스템 메모리로 활용하도록 제안

NV-Heaps: 안전 포인터 및 가비지 컬렉션과 같은 기능을 제공하지만 특정 프로그래밍 프레임워크 및 하드웨어 지원이 필요

인텔 PMDK 및 Mnemosyne과 같은 사용자 공간 라이브러리: NVM을 활용하며 가상화를 위해 실행 취소 로깅, 다시 실행 로깅, 스와핑 가능함. 단, Mnemosyne에는 DRAM 읽기 캐시와 프로세스 간 NVM의 공유 기능이 없다

method: NVM을 시스템의 스토리지 디바이스만큼 크고, DRAM만큼 빠르게 처리할 수 있도록 하는 것이 목표

트랜잭션이 커밋되기 전에 기록된 데이터를 저장하기 위해 임시 로그 버퍼로 비휘발성 메모리(NVM)를 사용: 쓰기 크리티컬 경로에서 매우 중요한 로깅 프로세스 중에 원자성과 내구성을 보장함으로써 성능 이점을 제공한다. => vNVML 시스템에서는 재실행 로깅을 사용, 쓰기 연산만 유지한다. (=NVM 수명 문제 해결) 로그 버퍼가 너무 꽉 차는 것을 방지하기 위해 커밋된 데이터는 로그 버퍼에서 저장 장치의 영구 저장 위치로 점진적으로 이동함

실행 취소 로깅: 새 데이터를 업데이트하기 전에 이전 데이터를 로그로 유지

다시 실행 로깅: 저장 장치를 업데이트하기 전에 모든 새 데이터를 로그로 유지

스토리지 장치에 데이터를 기록할 때

프라이빗 영역: 데이터가 로그 버퍼와 NVM 캐시에 기록

공유 영역: 데이터가 DRAM에서 스토리지 디바이스로 직접 기록되며 로그 버퍼는 복구 목적으로만 사용

메모리 매핑된 파일을 통해 바이트 주소 수준의 로드/저장 인터페이스를 제공

DRAM을 읽기 캐시로 활용: 트랜잭션이 커밋된 후 전체 로그 버퍼를 검색할 필요 없이 DRAM에서 데이터에 직접 접근할 수 있다. (= 읽기 연산 속도를 크게 향상)

experiment:

vNVML의 특성 및 실제 애플리케이션에서 사용할 때 성능에 미치는 영향: 캐시 크기 1GB, 로그 크기 2GB, 삽입된 레코드 3만 개에서 vNVML은 NVM을 성공적으로 가상화할 수 있으며, 로그 버퍼와 읽기 캐시에 데이터를 쓰면서 발생하는 오버헤드가 10% 미만

제한된 NVM에서 로그 버퍼와 캐시의 크기를 어떻게 결정해야 할지: write working set 크기가 커지면, 런타임 동안 데이터를 저장하기 위해 더 많은 NVM 캐시가 필요하다. 만약 write working set > NVM 캐시의 용량이 되면 캐시 페이지가 스토리지 디바이스에 다시 기록되어 성능이 저하된다.

실험결과 캐시 크기를 일정하게 유지할 때 로그 버퍼 크기를 조정하는 것이 전체 처리량에 미치는 영향이 미미하다. => 로그 버퍼의 크기보다 캐시의 크기가 시스템의 처리량에 더 큰 영향을 미친다 = NVM 리소스가 제한되어 있는 경우 로그 버퍼보다는 캐시로 더 많은 NVM을 할당하는 것이 더 바람직하다

여러 프로세스가 vNVML을 통해 NVM에 액세스할 때의 성능

컨테이너 환경에서 vNVML 사용: 도커 컨테이너 내에서 vNVML을 사용해도 성능에 큰 영향을 미치지 않는다

다른 라이브러리와 vNVML 비교: 인텔의 PMDK, SoftWrAP, vNVML와 비교 => 총 기록 데이터가 증가할수록 vNVML의 성능이 더 우수하며, NVM 크기를 8GB로 확대해도 성능은 비슷하게 유지됨

conclusion & discussion: vNVML은 읽기 캐싱에 DRAM을 활용하여 성능을 개선하고 쓰기 횟수를 줄여 잠재적으로 NVM 수명을 연장할 수 있다.

애플리케이션 간에 NVM을 공유해야 할 필요성: 동적인 워크로드가 있는 데이터 센터에서 가용 리소스를 효율적으로 활용하기 위함(NVM이 단일 애플리케이션에 할당되어 전용으로 사용되면 다른 애플리케이션에서 쉽게 재사용하거나 재할당할 수 없다) => 여러 애플리케이션에서 NVM을 공유할 수 있도록 지원함으로써 여러 워크로드에서 효과적으로 활용하고 공유할 수 있도록 하자
기존 저장 장치를 단순히 NVM으로 대체하는 것의 한계: 기존 저장 장치를 NVM으로 대체하게 되면, 개별 바이트나 주소가 아닌 블록 단위로 NVM에 접근하게 되어 바이트 주소 지정이 가능한 메모리 기술로서의 잠재력을 충분히 활용하지 못하게 된다.
NVM과 DRAM의 비슷한 접근 지연 시간: NVM 및 DRAM과 같은 고속 메모리 기술은 기존 저장 장치에 비해 접근 지연 시간이 현저히 낮기 때문에 시스템 호출 오버헤드가 병목이 된다. ex) 사용자 공간 -> 커널 공간으로 전환(컨텍스트 전환, 데이터 복사, 동기화 메커니즘 등)
NVM을 완전히 활용하기 위한 소프트웨어 수정의 잠재적 필요성: NVM을 지원하는 하드웨어에서 기존 소프트웨어를 계속 실행하는 것이 가능하긴 하지만, 성능 개선과 안정성 보장 측면에서 적절한 수정이 필요할 수 있음
읽기/쓰기 데이터의 흐름: 페이지 A와 B가 처음에 저장 장치에 저장된 후 액세스 시 메모리에 복사되고 로그 항목 ΔA와 ΔB로 업데이트되는 과정 => 커밋된 로그가 적용되어 업데이트된 페이지 A'와 B'가 생성된 다음 저장 장치에 다시 기록
- (a) 처음에 페이지 A와 B가 있는 스토리지의 파일.
- (b) 읽기연산: 페이지 A를 저장 장치에서 메모리로 복사한 다음 애플리케이션이 메모리에서 직접 페이지 A를 읽도록 한다.
- (c) 페이지 A에 쓰기연산: 로그 버퍼에 로그 ΔA가 추가
- (d) 페이지 B에 대한 또 다른 쓰기: 로그 ΔB가 로그 버퍼에 추가
- (e) 트랜잭션 커밋: 메모리의 페이지 A는 ΔA에서 페이지 A'로 업데이트된다. 페이지 B는 Copy-on-Write 메커니즘에 의해 스토리지에서 메모리로 복사된 후 ΔB에서 페이지 B'로 업데이트된다. (페이지 A와 B는 저장 장치에서 NVM 캐시로 읽혀지고 재실행 백그라운드 스레드에 의해 로그 ΔA와 ΔB가 페이지 A' 및 B'로 적용됨)
- (f) Writeback 백그라운드 스레드가 NVM 캐시에서 페이지 A' 및 B'를 저장 장치로 쓰기연산 실행
vNVML 알고리즘: 애플리케이션은 저장 장치에 있는 파일의 매핑 영역만 알 수 있으며, API를 통해 가상 NVM에 접근한다.
- nv_init(): 모든 애플리케이션(프로세스)은 vNVML을 활용하기 전에 먼저 vNVML을 초기화하고 NVM 캐시 및 로그 버퍼에 대한 매핑된 목록을 구성한다. shm_open 시스템 콜로 NVM에 파일(로그 버퍼, 캐시 및 관련 메타데이터)과 공유 메모리 객체를 생성한다.
- shm_open: 공유 메모리 개체를 만들거나 여는 Unix 계열 운영 체제의 시스템 호출
- nv_release(): 백그라운드 워커에 의해 커밋된 로그가 NVM 쓰기 캐시에 적용될 때까지 기다렸다가, 더티 페이지를 스토리지로 플러시하고 가상 메모리 공간에서 모든 NVM 파일의 매핑을 해제한다. 마지막 호출자/애플리케이션에 의해 호출되면 vNVML에 할당된 모든 리소스를 해제하고 모든 NVM 파일을 지운다.
- nv_allocate(파일경로, 크기, 매핑 모드): 저장 장치의 파일 경로, 파일 크기, 매핑 모드(프라이빗 또는 공유)와 같은 매개 변수를 기반으로 애플리케이션/프로세스에 대한 NVM의 가상 영역을 할당한다. 만약 기존 파일을 열 수 없는 경우에는 새 파일을 만든다.
- nv_free(파일 포인터, 크기): munmaps(fileptr,n) 함수를 호출한다. nv_init()에 의해 가상 주소 공간에 매핑된 NVM 파일의 매핑을 해제하는 역할을 한다.
- munmap: 프로세스의 가상 주소 공간에서 이전에 매핑된 메모리 영역의 매핑을 해제하는 Unix 계열 운영 체제의 시스템 호출
- nv_txbegin():단일 트랜잭션을 구성하기 위해 나중에 쓰기 작업(nv_write())에서 사용될 고유한 트랜잭션 ID를 생성한다.
- nv_write(트랜잭션 ID, 주소 dst, 주소 src, 길이): 가상 NVM에 재실행 로그로 데이터를 기록한다. 첫 번째 호출에서는 로그 버퍼에서 로그 페이지를 할당 하며, 사용 가능한 페이지가 없으면 지금까지 기록된 데이터 수를 반환한다. 로그는 특정 트랜잭션에 해당하는 open list 내에 링크드 리스트 노드 형태로 저장됨
- nv_commit(트랜잭션 ID): vNVML에서 트랜잭션을 커밋하는 역할을 담당한다. 먼저 vNVML은 특정 트랜잭션 내에서 기록된 모든 작업을 살펴보고 이를 "읽기 캐시"라는 별도의 영역에 기록한다.(다른 애플리케이션이 이후에 읽을 때 이전 트랜잭션에서 변경한 내용을 볼 수 있음) 기록된 모든 작업이 읽기 캐시에 성공적으로 기록되면, vNVML은 해당 로그 객체를 open list에서 NVM에 저장된 애플리케이션에 대한 메타데이터가 포함된 committed list이라는 다른 전용 목록으로 이동한다.(비휘발성 메모리 미디어에 저장함으로써 시스템 장애 또는 정전 시에도 내구성을 보장)
- nv_abort(트랜잭션 ID): 특정 트랜잭션ID의 로그를 open list에서 제거
vNVML 데이터 구조: NVM 로그 버퍼와 캐시는 링크드 리스트로 구성되며, 각 단위는 4KB 페이지이다. 단, 메모리의 일반적인 링크드 리스트와 달리 NVM에서는 가상 주소를 포인터로 사용할 수 없기 때문에 0부터 시작하는 페이지의 인덱스가 대신 사용되며, 링크드 리스트 내의 데이터 접근은 시작 주소로부터의 오프셋으로 대체된다.
- Page 객체: 로그 버퍼 및 캐시의 단위이며, 애플리케이션 ID, 파일 설명자, 오프셋 및 더티 플래그와 같은 정보를 포함한다.
- 로그 버퍼: 저장 장치에 다시 기록되기 전에 NVM에 변경 사항을 저장하는 데 사용되며, 변경 사항을 임시로 저장하여 시스템 장애 또는 충돌 시 데이터를 복구할 수 있도록 하는 역할
- 캐시 페이지: 읽기 캐싱에 사용되며, 파일에서 자주 접근하는 데이터를 DRAM 메모리로 옮겨서 접근 시간을 단축하는 데 사용된다. 잠재적으로 NVM에 대한 쓰기 횟수를 줄임으로써 성능을 개선하는 데 도움이 된다.
Background workers: nv_init을 실행하면 두 개의 백그라운드 워커가 생성된다.
- redo(재실행) 백그라운드 워커: 커밋된 목록을 지속적으로 확인하고, 로그 페이지에서 NVM 캐시 페이지로 로그 항목을 적용한다. 캐시 누락이 발생하는 경우에는 저장 장치에서 페이지를 읽는다.
- writeback 백그라운드 워커: 누적된 더티 페이지에 대한 임계값을 사용하여 더티 NVM 페이지를 스토리지 장치에 다시 쓰는 작업을 담당한다. 더티 페이지의 수가 특정 임계값 아래로 떨어지면 writeback 워커가 중지되고, nv_release 명령에 따라 두 워커가 모두 종료된다.
Sharing NVM between processes: NVM을 할당할 때 파일이 공유되고 메모리에 매핑되며, committed list 헤드는 공유된 각 파일에 대한 NVM의 메타데이터에 유지된다.

같이 읽어보면 좋을 만한 글이나 이슈가 있을까요?

인텔과 마이크론의 옵테인 NVM DIMM 협력으로 하드웨어를 크게 재설계하지 않고도 소프트웨어 기반 접근 방식으로 NVM을 관리할 수 있게 되었다.
DRAM과 NVM을 캐시로 활용하는 시스템 구조
NVM을 영구 저장소로 사용하는 경우 내구성과 쓰기 순서를 보장하는 것이 매우 중요하다.
- vNVML은 트랜잭션과 유사한 시맨틱을 활용하여 DRAM을 읽기 캐시로, NVM을 로그 버퍼 및 쓰기 캐시로, 백업 저장 장치를 쓰기의 최종 대상으로 사용하므로 원자성이 보장되지 않는 직접 NVM 액세스에 비해 처리량 오버헤드가 10% 미만으로 줄어듦

레퍼런스의 URL을 알려주세요! 🔗

markdown 으로 축약하지 말고, 원본 링크 그대로 그냥 적어주세요!

sypark9646 / paper-logs