전체 글

Linux 7.2 커널 릴리스, 캐시 인식 스케줄링과 GPU 스케줄러 변경 정리

xXfacebook페이스북

리눅스 커널 7.2가 2026년 8월 16일 정식으로 나왔습니다(kernel.org 기준). 스케줄러가 스레드를 어디에 배치하는지, 메모리를 어떻게 큰 페이지로 묶는지, 그리고 14년 동안 조용히 데이터를 망가뜨리던 버그 하나까지 손을 댄 릴리스입니다. 서버를 운영하거나 자기 워크로드의 CPU 배치를 신경 쓰는 사람이라면 읽어 둘 값이 있습니다.

한 가지 먼저 짚습니다. 7.2가 나왔다고 해서 이게 곧 최신 안정판인 것은 아닙니다. 같은 시점에 7.1.9 stable 이 함께 유지되고 있습니다. 지금 프로덕션에 올려야 하는 버전이냐는 별개의 판단입니다. 이 글은 정식 릴리스에 담긴 변경점을 원문 기준으로 정리합니다. 업그레이드 판단은 맨 뒤에서 따로 다룹니다.

리눅스 7.2 릴리스의 주요 변경점을 스케줄링, 메모리, GPU, 버그 수정 네 갈래로 나눈 개요 다이어그램

리눅스 7.2의 변경점을 스케줄링·메모리·GPU·버그 수정으로 나눈 개요다.

Linux 7.2, 무엇이 바뀌었나

이번 주기의 규모에 대해 정리 글은 "역대 가장 바빴던 주기 중 하나이며, 오직 6.7에만 밀렸다"고 적었습니다. 그리고 이런 규모가 이제 "새로운 표준(new normal)"으로 여겨진다고 덧붙였습니다. 구체적인 커밋 수나 변경 라인 수, 참여 개발자 수 같은 수치는 원문에 나와 있지 않으므로 여기서도 숫자로 옮기지 않겠습니다. "바빴다"는 것은 질적인 평가로만 받아들이는 편이 정확합니다.

넘버링에 헷갈릴 필요는 없습니다. 6.x 다음이 7.x 로 넘어간 것은 정상적인 흐름이고 큰 아키텍처 단절을 뜻하지 않습니다. 아래에서는 이번 릴리스에서 눈에 띄는 변경을 스케줄링, 메모리·GPU, 그 밖의 수정 순서로 하나씩 풀어 봅니다.

캐시 인식 스케줄링 — 코어 배치가 바뀐다

가장 실질적인 변화는 스케줄러가 스레드를 깨울 때 어느 CPU 에 올릴지 고르는 방식입니다. 7.2 의 캐시 인식 스케줄링(cache-aware scheduling)은 스레드를 깨울 때 같은 프로세스의 스레드를 가장 오래 실행했던 CPU 를 고릅니다. 한 프로세스의 스레드들을 같은 캐시 도메인(LLC, Last-Level Cache) 안에 모으려는 것입니다. 이전 스케줄러는 자원을 공유하는 태스크 그룹을 따로 식별하지 않았습니다. 같은 캐시를 나눠 쓰는 스레드들이 물리적으로 가까운 코어에 모이면 캐시 적중률이 올라가는 것을 노린 변경입니다.

물론 무작정 한곳에 몰면 그 도메인이 과부하가 됩니다. 그래서 제동 장치가 있습니다. 어떤 태스크가 그 도메인에서 CPU 시간의 25%를 초과해 쓰거나 전체 부하의 33%를 초과하면 그리로 옮기지 않습니다. 다만 여기엔 아직 남은 문제가 있습니다. 기존 로드 밸런서는 부하를 코어 사이에 고르게 흩뿌리려 합니다. 그래서 캐시 인식 로직과 방향이 엇갈리면 태스크가 캐시 도메인 사이를 왔다 갔다 튈 수 있습니다. 즉 이것은 완성된 최종 해법이 아니라 앞으로 다듬어질 출발점에 가깝습니다.

스레드를 깨울 때 같은 프로세스의 스레드들을 하나의 LLC 캐시 도메인에 모으는 캐시 인식 스케줄링의 동작을 나타낸 그림

같은 프로세스의 스레드를 하나의 LLC 도메인에 모으되, 25%·33% 상한을 넘으면 옮기지 않는다.

sched_ext 서브 스케줄러 — cgroup마다 다른 스케줄러

7.2 는 BPF 기반 스케줄러 프레임워크인 sched_ext 를 한 단계 더 밀었습니다. 이제 cgroup 에 스케줄러를 붙일 수 있습니다. 워크로드마다 서로 다른 스케줄러를 동시에 돌릴 수 있다는 뜻입니다. 중첩은 최대 4단계까지 가능하고 각 태스크는 자기 cgroup(또는 가장 가까운 조상 cgroup)에 붙은 스케줄러의 지배를 받습니다.

역할이 층으로 나뉘는 것이 핵심입니다. 부모 스케줄러는 워크로드가 언제 돌지를 정합니다. 서브 스케줄러는 그 워크로드 안에 있는 프로세스들이 CPU 에 어떻게 접근할지를 정하고, CPU 컨트롤러는 CPU 시간의 총량을 제한합니다. 서로 다른 성격의 워크로드가 한 머신에 섞여 있을 때 각자에게 맞는 정책을 따로 줄 수 있게 된 셈입니다. 안전장치도 있습니다. 어떤 서브 스케줄러가 실패해 bypass 되더라도 부모 스케줄러가 그 자리를 이어받아 전체가 무너지지 않도록 했습니다.

부모 스케줄러, 서브 스케줄러, CPU 컨트롤러가 cgroup 계층에서 각각 다른 역할을 맡는 sched_ext 중첩 구조를 나타낸 그림

부모 스케줄러는 언제 돌지, 서브 스케줄러는 어떻게 접근할지, CPU 컨트롤러는 얼마나 쓸지를 나눠 맡는다.

메모리와 GPU — THP 자동 생성과 DRM 스케줄러

메모리 쪽에서는 khugepaged 가 투명 거대 페이지(THP, Transparent Huge Page)를 자동으로 만드는 범위가 넓어졌습니다. 이전에는 PMD 크기(2MB)의 거대 페이지 위주였다면 7.2 에서는 여러 크기의 mTHP(multi-size THP)를 자동으로 생성합니다. 방식은 이렇습니다. 2MB 청크 단위의 비트맵으로 지금 사용 중인 기본 페이지들을 식별한 뒤, 먼저 PMD 로 병합을 시도합니다. 실패하면 점점 더 작은 mTHP 크기로 내려가며 시도합니다. 큰 페이지로 묶으면 TLB 가 한 번에 덮는 메모리가 넓어집니다. 정리 글은 그 조건을 "정렬되고 물리적으로 연속된 페이지 8개(x86) 또는 16개(Arm)"로 적었습니다. 참고로 MGLRU 쪽에도 개선이 있었다는 언급이 있지만 세부 메커니즘은 원문이 다루지 않으므로 여기서는 "개선이 있었다"는 수준으로만 남깁니다.

GPU 쪽은 기대와 결과가 갈립니다. DRM 스케줄러에 공정(fair) 정책이 들어오긴 했는데 회귀(regression) 때문에 기본값이 되지 못하고 옵트인으로 남았습니다. 7.2 에서 기본 정책은 여전히 기존 FIFO 이고 공정 스케줄러를 쓰려면 명시적으로 켜야 합니다. 재활성화(기본값 전환)는 다음 릴리스에서로 예상됩니다. "7.2 부터 공정 스케줄러가 기본"이라는 말은 틀린 설명이니 주의가 필요합니다.

그 밖의 수정 — 14년 묵은 futex 버그, 라즈베리파이 GPU

이번 릴리스에서 눈에 띄는 버그 수정은 futex 의 robust list 메커니즘에 있던 14년 묵은 버그입니다. 이 버그는 특정 엣지 케이스에서 데이터 손상을 일으켰고, Igalia 가 해법 설계와 반영에 참여해 7.2 에 담겼습니다. 오래 잠복해 있던 만큼 반가운 수정입니다. 다만 패치의 커밋이나 구체적인 수정 방식 같은 기술 세부는 확인되지 않았으므로 "robust list 에서 데이터가 손상되던 14년 된 버그가 7.2 에 수정 반영되었다"는 사실까지만 옮깁니다.

라즈베리파이 쪽 변경은 두 갈래인데 섞이지 않게 나눠 봅니다. 하나는 라즈베리파이 4·5 의 GPU 에 런타임 전력관리가 추가된 것입니다. 이전에는 GPU 가 기기 수명 내내 켜져 있었는데 이제 유휴 상태에서 GPU 클럭을 낮춥니다. 다른 하나는 이와 별개로 라즈베리파이 3 의 GPU 드라이버에 있던 오래된 버그 2건을 고친 것입니다. 이 버그들은 무작위 GPU 멈춤과 시스템 전체 크래시를 일으켰습니다. 4·5 의 전력관리와 3 의 버그 수정은 서로 다른 작업이니 하나로 뭉쳐 이해하지 않는 편이 좋습니다.

지금 올려야 하나

7.2 는 스케줄링·메모리 쪽에서 방향성이 뚜렷한 릴리스입니다. 다만 앞서 본 것처럼 캐시 인식 스케줄링은 로드 밸런서와의 충돌 여지가 남아 있고 DRM 공정 스케줄러는 아직 옵트인입니다. 정식 릴리스와 별개로 7.1.9 stable 이 함께 유지되고 있습니다. 그러니 새 커널이 나왔으니 바로 올린다기보다는 내 워크로드가 위 변경점 중 무엇에 닿는지를 먼저 확인하는 게 순서입니다.

CPU 캐시 지역성에 민감한 멀티스레드 서버라면 캐시 인식 스케줄링의 효과와 도메인 튐 현상을 테스트 환경에서 먼저 재 볼 값이 있습니다. 한 머신에 성격이 다른 워크로드를 섞어 돌린다면 sched_ext 서브 스케줄러가 실험해 볼 만한 지점입니다. 반대로 특별히 걸리는 게 없다면 안정성을 우선해 stable 계열을 유지하며 다음 포인트 릴리스들을 지켜보는 선택도 충분히 합리적입니다. 이 글의 수치와 조건은 모두 아래 원문에서 확인한 것이며 도입 전에는 각자의 환경에서 직접 검증하시길 권합니다.

근거와 참고

Published Aug 21, 2026

이 글 공유하기xXfacebook페이스북

긱뉴스에서 고른 소식을 읽고 정리합니다.