Linux Zswap의 새로운 패치가 주요 개선 사항을 보여주다

LINUX KERNEL

Linux 개발자 Usama Arif가 Zswap의 요청 경합(request contention)을 줄이기 위한 두 개의 패치 세트를 작업 중으로 게시했습니다. zRAM에 적용된 유사한 작업을 따라, Zswap 코드는 저장(stores)과 로드(loads)가 per-CPU acomp 요청 및 뮤텍스(mutex)를 공유하는 현재의 단점을 해결하기 위해 조정되고 있습니다. 이 현재 처리 방식은 궁극적으로 병목 현상을 초래하고 있으며, 두 개의 패치는 로드의 경합을 줄이는 데 도움을 줍니다.

Usama Arif는 패치 커버 레터에서 더 자세히 설명했습니다:

"저장과 로드는 per-CPU acomp 요청 및 뮤텍스를 공유합니다. 낮은 우선순위의 저장 작업은 압축기(compressor)가 스트림 잠금(stream lock)을 해제한 직후, 여전히 zswap 뮤텍스를 보유하고 있을 때 선점될 수 있으며, 그 CPU에서 더 높은 우선순위의 로드는 저장 작업이 다시 실행되기를 기다립니다. 이는 같은 이유로 분리한 Sergey Senozhatsky의 zram 시리즈 작업을 따릅니다.

패치 1은 압축 및 압축 해제에 별도의 요청(requests), 대기(waits) 및 뮤텍스를 부여하여, 로드가 더 이상 저장 작업을 기다리지 않게 합니다. 다만 여전히 서로를 기다릴 수는 있습니다. 패치 2는 알고리즘이 동기식(synchronous)이고 요청 컨텍스트가 필요하지 않을 때 스택 상의 요청으로 압축 해제하며, 이는 모든 in-tree 소프트웨어 압축기를 포괄하여 해당 로드가 zswap 잠금을 사용하지 않게 합니다. 비동기(Asynchronous) 알고리즘은 per-CPU 요청 및 뮤텍스를 유지합니다. 소프트웨어 압축기의 경우 시리즈는 이전과 동일한 수의 요청을 할당하며, 각 per-CPU 컨텍스트가 72바이트 증가하고 x86-64에서 로드 경로는 약 270바이트 더 깊어집니다."

무엇이 인상적인지는 최종 결과입니다:

Usama는 패치 시리즈와 함께 더 자세히 설명했습니다:

아래 수치는 5회 실행의 중앙값(최소-최대)으로 측정된 실행당 가장 느린 읽기 시간입니다. 각 실행은 zstd VM, lazy preemption, vm.page-cluster=0 및 /dev/ram0에 스왑이 활성화된 환경에서 12초 동안 진행됩니다. vCPU 1개로 네 개의 nice +10 워커가 페이지 메모리를 내보내고(out) nice 0 작업이 회전하는 동안 이를 다시 읽어옵니다. nice -19 리더는 자체 버퍼를 페이지 아웃하고 각 읽기 시간이 얼마나 걸리는지 측정합니다. vCPU 8개로 구성된 환경에서는 워커 16개, 스피닝 작업 8개, 리더 8개가 있습니다.

읽기 시간이 10ms를 초과하는 경우는 vCPU 1개 환경에서는 실행당 2635회에서 아예 없게 되었으며, vCPU 8개 환경에서는 실행당 318회에서 최대 1회로 줄었습니다. 이 벤치마크와 테스트 프로그램은 LLM의 도움을 받아 작성되었습니다.