리눅스 커널 7.2 릴리스 — 캐시 인지 스케줄링 도입, DRM Fair 스케줄러는 막판 되돌림

리누스 토발즈가 8월 16일(현지 시간) 리눅스 커널 7.2를 릴리스했습니다. 병합 창구에서만 13,412개의 non-merge 커밋이 들어와 2024년 6.7 사이클 이후 가장 바쁜 주기였습니다. 토발즈는 릴리스 공지에서 “마지막 한 주가 또 한 번 바라던 것보다 컸지만, ‘뉴 노멀’을 이유로 릴리스를 미루기 시작하면 영영 릴리스를 못 할 것”이라고 적었습니다. AI 도구가 만들어내는 리뷰와 수정 패치가 커널 사이클의 기본 규모를 끌어올린 상황을 그대로 보여주는 문장입니다. 이 글에서는 7.2에서 실제로 무엇이 바뀌었는지, 그리고 막판에 되돌려진 변경 하나를 정리합니다.

Contents:

캐시 인지 스케줄링

이번 릴리스의 간판 기능은 캐시 인지 스케줄링(Cache Aware Scheduling)입니다. 팀 첸(Tim Chen), 첸 유(Chen Yu), 피터 지일스트라(Peter Zijlstra) 등이 오랫동안 다듬어온 패치가 마침내 들어갔습니다. 문제의식은 단순합니다. LLC(Last Level Cache) 도메인이 여러 개인 최신 서버 CPU에서 같은 데이터를 공유하는 스레드들이 서로 다른 L3에 흩어지면 캐시 미스와 캐시 바운싱이 발생합니다.

해결 방식은 프로세스마다 선호 LLC를 지정하고, 주기적 로드 밸런싱 과정에서 그 프로세스의 스레드들을 선호 LLC 쪽으로 모으는 것입니다. 다만 무조건 모으지는 않습니다. LLC별 사용률을 주기적으로 샘플링해 특정 캐시 도메인이 과부하로 기울면 이동을 제한합니다. 동작은 debugfs 노브로 조정할 수 있습니다.

노브 (`/sys/kernel/debug/sched/`)	기본값	역할
`llc_aggr_tolerance`	0~100	모으기 적극성. 0이면 기능 비활성, 값이 클수록 메모리 사용량·스레드 수와 무관하게 더 많은 프로세스를 대상으로 삼음
`llc_overload_pct`	50%	이 사용률 아래면 선호 LLC로 자유롭게 이동
`llc_imb_pct`	20%	LLC 간 사용률 차이 허용치. 넘으면 이동을 제한
`llc_epoch_period`	10ms	LLC 점유율 샘플링 주기
`llc_epoch_affinity_timeout`	50ms	유휴 프로세스가 선호 LLC를 잃기까지의 시간

효과는 하드웨어 구성에 따라 갈립니다. 인텔 사파이어 래피즈 2소켓(LLC당 60 CPU)에서는 hackbench 1그룹이 약 30% 개선됐고, schbench의 wakeup latency는 스레드 수가 많은 구간에서 22~38% 좋아졌습니다. AMD 제노아(4노드, 노드당 32 CPU)에서는 공격적인 설정 기준 ChaCha20 워크로드 처리량이 44% 늘었습니다. 반면 AMD 밀란에서는 거의 차이가 없었고, stream이나 netperf처럼 데이터 공유가 적은 워크로드도 영향이 미미했습니다. 여러 LLC 도메인을 가진 서버가 아니라면 체감할 일이 없는 기능입니다.

구현상 한계도 남아 있습니다. 선호 LLC가 과부하일 때 2순위 LLC로 옮기는 로직은 일부러 넣지 않았습니다. 과도한 마이그레이션이 오히려 지역성을 깨고 1순위·2순위 캐시 사이에서 바운싱을 유발할 수 있다는 판단입니다.

막판에 되돌린 DRM Fair 스케줄러

7.2 병합 창구에서는 DRM GPU 스케줄러의 기본 정책이 FIFO에서 CFS를 참고한 fair 정책으로 바뀌었습니다. AMDGPU를 비롯한 여러 DRM 드라이버가 쓰는 공용 스케줄러라 파급 범위가 넓은 변경이었습니다. 그런데 릴리스 직전 주말에 심각한 회귀 보고가 올라왔습니다.

증상은 라데온 RX 9070 XT에서 게임으로 GPU를 100% 부하로 지속시킬 때 나타났습니다. 포그라운드 애플리케이션이 10fps 수준까지 떨어지거나, 소리는 계속 나는데 화면만 멈추는 상태가 됐습니다. KDE 플라스마 Wayland 세션 전체가 잠겨 컴포지터를 죽이거나 재부팅해야 복구되는 사례도 보고됐습니다.

fair 스케줄러 작업을 주도한 이갈리아(Igalia)의 트브르트코 우르술린(Tvrtko Ursulin)은 되돌리기로 결정했고, 20개 패치 시리즈가 DRM fixes pull request에 실려 최종 릴리스에 반영됐습니다. 코드 자체가 빠진 것은 아니고 experimental로 표시된 채 남았습니다. 이미 회귀를 고치는 패치가 올라와 있어, 문제가 정리되면 다음 사이클에서 다시 기본값이 될 가능성이 큽니다.

메모리와 스토리지

메모리 관리 쪽 변화가 눈에 띕니다. 스왑 테이블 작업 4단계가 들어가면서 익명 페이지와 shmem의 스왑 할당 경로가 folio 기준으로 통합됐습니다. 그 결과 정적 메타데이터 오버헤드가 거의 0에 수렴해, 1TB 스왑 장치를 마운트할 때 약 512MB를 아낍니다. MGLRU도 정리와 최적화를 거쳐 YCSB를 돌린 MongoDB 같은 워크로드에서 최대 30% 수준의 개선이 보고됐습니다. khugepaged가 multi-size THP를 자동으로 만들도록 바뀐 것도 이번 사이클입니다.

파일시스템에서는 Btrfs가 large folio를 기본 활성화하고 2MB huge folio를 실험적으로 지원합니다. 원시 체크섬을 읽는 GET_CSUMS ioctl이 추가됐고, 순차 쓰기와 다이렉트 I/O 성능도 손봤습니다. ext4는 fast commit을 대폭 재작업했고, exFAT은 iomap 인프라로 전환했습니다. NFS는 램 16GB 이상인 시스템에서 기본 블록 크기를 4MB로 올렸고, NFSD에는 CB_NOTIFY 기반 디렉터리 위임이 들어갔습니다. 블록 계층에는 인라인 암호화를 지원하는 장치를 위한 dm-inlinecrypt 디바이스 매퍼 타깃이 새로 추가됐습니다.

네트워크와 보안

인텔이 개발한 USB4STREAM이 들어와 /dev/tbstreamX 장치를 통해 USB4 케이블로 직접 데이터를 주고받을 수 있게 됐습니다. 기존 썬더볼트 네트워킹과 달리 네트워크 스택 설정 없이 read()/write()만으로 단순 전송이 가능합니다. MPTCP는 연결당 서브플로 수 상한이 8개에서 64개로 늘었습니다.

보안 쪽에서는 Landlock이 UDP 소켓 사용까지 제어할 수 있게 됐습니다. openat(2)에는 FIFO나 디바이스 노드로 경로가 바꿔치기되는 것을 막는 OPENAT2_REGULAR 플래그와, 이미 열린 파일을 다시 여는 O_EMPTYPATH가 추가됐습니다. IMA는 측정 데이터를 커널 메모리 밖에 준비해둘 수 있게 됐고, KVM은 인텔 MBEC와 AMD Guest-Mode Execution Trap을 지원합니다.

하드웨어 지원과 Rust

하드웨어 지원은 AMD Zen 6 준비 작업이 이어졌습니다. 최근 출시된 EPYC 9006 “베니스(Venice)” 시리즈를 포함해 기본 기능은 메인라인에서 정상 동작하는 수준까지 올라왔습니다. 인텔 TDX는 재부팅 없이 런타임에 보안 업데이트를 적용할 수 있게 됐습니다. 애플 M3 기기가 7.2 커널로 부팅되기 시작했지만, 일반 사용자가 쓸 만한 단계는 아직 아닙니다. AMDGPU에는 HDMI 2.1 FRL 초기 지원이 들어갔으나 기본 비활성 상태이고, VRR이나 ALLM 같은 나머지 HDMI 2.1 기능은 이번에 포함되지 않았습니다. HP ZBook Ultra G1a 등의 웹캠을 살리는 AMD ISP4 드라이버도 병합됐습니다.

Rust는 s390 아키텍처에서도 커널 Rust 코드를 빌드할 수 있게 됐고, 소프트웨어 태그 기반 KASAN과 AutoFDO를 지원합니다. 빌드 시스템은 SPDX 정보를 이용해 SBOM을 생성할 수 있게 됐습니다.

6년 만에 끝난 strncpy() 정리

이번 사이클에서 커널의 strncpy() 구현이 완전히 제거됐습니다. 6년에 걸쳐 70명의 기여자가 362개 커밋을 넣어 호출부를 하나씩 걷어낸 결과입니다. 목적지 버퍼를 널 종료하지 않을 수 있는 이 함수의 사용을 아예 불가능하게 만든 셈입니다.

레거시 정리는 다른 곳에서도 이어졌습니다. FPU가 없는 프로세서를 위한 i486 시절 부동소수점 에뮬레이션 코드 13,000줄 이상이 사라졌고, EROFS의 fscache 백엔드도 폐기 후 제거됐습니다. 내보내는 심볼(exported symbol)은 195개가 빠지고 380개가 추가됐습니다.

정리

7.2는 서버 워크로드에 직접 영향을 주는 변경이 많은 릴리스입니다. 다중 LLC 서버를 운영한다면 캐시 인지 스케줄링의 debugfs 노브를 실제 워크로드로 실측해볼 가치가 있고, 대용량 스왑을 쓰는 환경이라면 스왑 테이블 통합으로 줄어든 메타데이터 오버헤드가 바로 체감됩니다. 데스크톱 사용자 입장에서는 DRM fair 스케줄러가 되돌려진 덕분에 7.2에서는 GPU 스케줄링 동작이 7.1과 같습니다.

7.3 사이클은 이미 시작됐습니다. 초기 pull request에는 오래된 파일시스템 몇 개를 제거하고 새 의사 파일시스템을 추가하는 변경이 포함돼 있습니다. fair 스케줄러가 다시 기본값을 노리는 것도 이 사이클이 될 가능성이 큽니다.