Linux kernel 7.2 캐시 인식 스케줄링 VPS 적용 여부

Linux kernel 7.2의 새로운 기능

Linux kernel 7.2는 2026년 8월 16일에 릴리스되었습니다. 주목할 만한 변경 사항은 새로운 CONFIG_SCHED_CACHE 옵션으로 구현된 캐시 인식 스케줄링(cache aware scheduling)입니다. 이제 스케줄러는 동일한 LLC(last level cache)를 공유하는 CPU에서 한 프로세스의 스레드를 유지하려고 시도합니다. 이 릴리스에서 워크로드가 CPU에 배치되는 방식에 영향을 주는 다른 변경 사항은 없습니다.

7.2 버전의 나머지 변경 사항을 요약하면 다음과 같습니다. ext4 fast commit 경로 재작업, MGLRU(multi-generational least recently used 메모리 회수 코드) 개선, 인라인 블록 장치 암호화를 위한 새로운 dm-inlinecrypt 장치 매퍼 타겟 추가, 그리고 커널 소스에서 마지막 strncpy() 호출이 제거되었습니다.

주요 기능이 사용자에게 유용한지 결정하는 단 하나의 사실이 있으므로 이를 먼저 설명합니다. 캐시 인식 로드 밸런싱은 NUMA(non-uniform memory access) 노드에 하나 이상의 LLC가 포함된 경우에만 활성화됩니다. VPS 게스트는 일반적으로 이러한 레이아웃을 표시하지 않으므로, 대부분의 게스트에서는 코드가 컴파일되어 포함되더라도 실제로 작동하지 않습니다. 이를 확인하는 방법은 아래의 "VPS 게스트에서 이 기능을 확인할 수 있는가" 섹션에 있는 두 가지 명령어를 참조하십시오.

이 페이지의 모든 기술적 주장은 2026년 8월 18일에 확인된 7.2 변경 로그와 캐시 인식 스케줄링 패치 시리즈 자체에서 가져온 것입니다. 출처는 마지막 부분에 나열되어 있으므로 사용 중인 커널과 비교하여 확인할 수 있습니다.

스케줄러가 캐시 정보를 알아야 하는 이유

현대적인 서버 소켓은 단 하나의 최종 레벨 캐시(LLC)를 가지지 않습니다. AMD EPYC 패키지는 여러 코어 컴플렉스로 구성되며, 각 컴플렉스는 고유한 L3 캐시를 가집니다. 최근 Intel Xeon 프로세서 역시 하나의 소켓을 여러 캐시 도메인으로 분할합니다. 따라서 단일 NUMA 노드 내에 4개, 8개 이상의 개별 LLC가 존재할 수 있으며, 동일한 프로그램의 두 스레드가 서로 다른 캐시 도메인에 배치될 수 있습니다.

이러한 배치 방식은 성능 저하를 유발합니다. 두 스레드가 서로 다른 LLC에서 동일한 메모리 페이지를 공유하면, 각 캐시는 해당 라인의 복사본을 각각 유지합니다. 한쪽에서 쓰기 작업이 발생하면 다른 쪽의 복사본은 무효화되며, 다음 읽기 작업 시 인터커넥트를 통과하거나 메인 메모리까지 접근해야 합니다. 이를 캐시 바운싱(cache bouncing)이라고 합니다. 이는 CPU 유휴 시간이 아닌 대기 시간으로 소모되는 사이클로 나타나며, 이 때문에 로드 에버리지(load average)를 모니터링할 때 간과하기 쉽습니다.

7.2 버전 이전의 로드 밸런서는 부하, 사용률, 유휴 CPU를 기준으로 작업을 배치했습니다. 당시에는 "이 두 작업이 동일한 메모리를 읽는다"는 정보를 입력받을 방법이 없었습니다. 7.2 버전에서는 계산 비용이 들지 않는 근사치를 사용하여 이 문제를 해결했습니다. 프로세스의 스레드들은 하나의 주소 공간을 공유하므로, 이들이 데이터를 공유할 가능성이 높다고 간주하여 스케줄링에 반영합니다.

커널이 선호 LLC를 선택하는 방법

이 추적 기능은 하나의 주소 공간을 나타내는 커널 구조체인 mm_struct에 프로세스 단위로 연결됩니다. 커널은 해당 프로세스의 스레드가 어디에서 실행 중인지 주기적으로 샘플링하여, LLC별로 프로세스가 얼마나 점유하고 있는지 계산합니다. 가장 많은 점유율을 보이는 LLC가 해당 프로세스 전체의 선호 LLC로 지정되며, 이후의 모든 결정은 이 단일 값을 기준으로 이루어집니다.

이후 두 가지 경로에서 이 값을 사용합니다. 스케줄러는 프로세스가 깨어날 때 노드 내의 유휴 CPU를 무작위로 선택하는 대신, 프로세스가 선호하는 LLC의 CPU를 우선적으로 선택합니다. 부하 분산(load balancing) 과정에서 태스크를 스케줄러 그룹 간에 이동시켜야 할 때, 이미 대상 LLC를 선호하는 태스크를 우선적으로 이동시키며, 태스크가 선호하는 LLC에서 강제로 분리하는 상황을 방지합니다.

이 기능만큼이나 안전장치도 중요합니다. 바쁜 프로세스의 모든 스레드를 하나의 캐시 도메인에 몰아넣으면 해당 도메인에 과부하가 걸리는 반면, 소켓의 나머지 부분은 유휴 상태로 남을 수 있기 때문입니다. 조정 가능한 설정값들은 커널의 디버그 파일 시스템인 debugfs의 /sys/kernel/debug/sched/ 경로 아래에 위치합니다.

• llc_aggr_tolerance은 0에서 100 사이의 값으로, 커널이 얼마나 적극적으로 집계할지를 결정합니다. 0는 런타임에 캐시 인식 스케줄링 기능을 끕니다. 1은 신중한 설정입니다. RSS(resident set size, 상주 메모리 크기)가 LLC보다 크거나, LLC의 코어 수보다 더 많은 스레드를 실행하는 프로세스는 현재 위치에 그대로 둡니다. 100는 크기나 스레드 수에 관계없이 무조건 집계합니다.
• llc_overload_pct(기본값 50)는 선호 LLC를 '사용 중'으로 간주할 기준이 되는 평균 사용률입니다.
• llc_imb_pct(기본값 20)은 선호 LLC가 과부하 상태에 도달했을 때, 집계 기반 마이그레이션으로 인해 발생할 수 있는 불균형의 상한선을 설정합니다.
• llc_epoch_period(기본값 10 ms)는 점유율을 수집하는 주기입니다.
• llc_epoch_affinity_timeout(기본값 50 ms)은 비활성 프로세스가 선호 설정을 유지하는 시간이며, 이 시간이 지나면 커널은 설정을 삭제합니다.

설정값을 변경하기 전에 먼저 현재 값을 확인하십시오. 배포판마다 기본값이 다를 수 있습니다: sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance.

어떤 워크로드가 이득을 보고 어떤 워크로드가 그렇지 않은가

아래 수치는 패치 시리즈와 함께 게시된 수치이며, 서버급 하드웨어에서 측정되었습니다. 일부는 허용 오차 범위를 공격적으로 설정한 상태에서 측정되었습니다. 이 수치는 베어메탈 환경에서의 최상의 사례로 이해해야 하며, 귀하의 장비에서 동일한 성능을 보장하는 것은 아닙니다.

[
  {
    "label": "hackbench, 1 group, Xeon Sapphire Rapids",
    "gain_pct": 30.57
  },
  {
    "label": "schbench, 4 threads, p99 wakeup latency, Sapphire Rapids",
    "gain_pct": 37.78
  },
  {
    "label": "ChaCha20 throughput, AMD Genoa, aggressive tolerance",
    "gain_pct": 44
  }
]

단일 그룹을 사용한 Hackbench는 30.57% 향상되었으며, AMD Genoa에서 실행한 ChaCha20 처리량은 44% 향상되었습니다. 모든 3개의 결과는 테스터가 처음부터 끝까지 제어한 다중 LLC 서버 하드웨어에서 측정되었습니다.

이득을 보는 워크로드의 형태는 다음과 같습니다.

• 단일 프로세스 내에 스레드가 두 개 이상 존재하여 그룹화할 대상이 있는 경우.
• 해당 스레드 간에 실제 데이터 공유가 발생하여, 캐시 라인 바운싱(bounced cache line) 비용이 실제로 발생하는 경우.
• 작업 세트(working set)가 하나의 LLC 내에 들어가는 경우. 프로세스가 캐시보다 크면 이동을 통해 캐시 지역성을 확보할 수 없기 때문입니다.
• 시스템에 여유 자원이 있어 스케줄러가 다음 스레드를 배치할 때 실질적인 선택권이 있는 경우.

반면, 아무런 이득이 없는 경우는 다음과 같습니다.

• 시스템이 이미 최대 부하 상태인 경우. 모든 CPU가 바쁘기 때문에 배치가 강제되어 보고된 이득이 사라집니다.
• 단일 스레드 프로세스이거나, 데이터를 공유하지 않는 독립적인 프로세스 풀인 경우.
• 작업 세트가 LLC보다 훨씬 커서, 신중한 llc_aggr_tolerance 설정이 의도적으로 건너뛰는 경우.
• LLC를 하나만 보고하는 노드의 경우. 이 기능이 전혀 활성화되지 않습니다.

비용 측면도 존재하며, 해당 시리즈는 이를 명시하고 있습니다. 점유율을 수집하는 작업은 태스크 컨텍스트 내에서 수행되므로, 일부 실행에서는 해당 작업이 태스크의 사용자 공간 복귀를 지연시켜 요청 지연 시간이 악화되는 현상이 나타났습니다. 집계 과정은 평균 처리량이 향상되더라도 지연 시간의 편차를 높일 수 있습니다. 평균보다 꼬리 지연 시간(tail latency)이 중요하다면, 직접 꼬리 지연 시간을 측정하십시오.

VPS 게스트가 이 내용을 확인할 수 있습니까

두 가지 사실이 답을 결정합니다.

첫째, 이 기능은 토폴로지에 따라 제한됩니다. 캐시 인식 로드 밸런싱은 하나의 NUMA 노드 내에 LLC가 두 개 이상 존재할 때만 활성화되며, 커널은 토폴로지 설정 과정에서 이를 기록합니다. 노드가 단일 LLC를 보고하는 경우, 튜닝 가능한 설정값과 관계없이 캐시 인식 경로는 비활성화 상태로 유지됩니다.

둘째, 게스트가 읽는 캐시 토폴로지는 호스트의 것이 아닙니다. 하이퍼바이저의 CPU 모델이 제공하는 정보일 뿐입니다. 기본 KVM (kernel based virtual machine) 게스트는 일반적으로 호스트의 실제 L3 레이아웃을 전달받지 않으므로, 게스트는 단순화된 정보를 바탕으로 판단합니다.

자신의 게스트가 무엇을 보는지 확인하십시오:

systemd-detect-virt
lscpu --caches
cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u

index3는 대부분의 x86 CPU에서 L3 캐시를 의미합니다. 모든 vCPU가 한 줄로 나열된다면 게스트는 단일 LLC를 보고 있는 것이며, 따라서 이 기능이 조정할 대상은 없습니다. No such file or directory은 게스트에게 L3가 전혀 노출되지 않았음을 의미하며, 이 경우 게스트는 하드웨어의 실제 경계가 아닌 하이퍼바이저가 임의로 설정한 경계를 기준으로 하위 캐시 레벨을 최종 레벨로 간주합니다.

다음으로 이중 스케줄링 문제가 있는데, 이는 모든 테넌트가 주의해야 할 솔직한 경고입니다. 게스트 커널은 스레드를 vCPU에 배치합니다. 호스트 커널은 해당 vCPU 스레드를 물리적 코어에 배치합니다. 4개의 스레드를 vCPU 0번에서 3번까지 신중하게 그룹화한 게스트는 4개의 호스트 스레드에 대한 선호도를 표현한 것이지만, 호스트는 이를 서로 다른 물리적 캐시 도메인에 배치하거나 나중에 이동시킬 자유가 있습니다. 게스트의 결정이 틀린 것은 아니지만, 그것이 최종 결정은 아닙니다. 이는 노이즈 이웃이 vCPU에 남기는 스틸 타임을 발생시키는 것과 동일한 계층 경계입니다.

그렇다면 이 기능은 VPS 테넌트에게 어떤 영향을 미칠까요? 두 가지 경우입니다. 전용 코어나 레이아웃이 패스스루(passed-through)된 대형 인스턴스처럼 토폴로지가 가상이 아닌 실제인 플랜에서는 게스트 스케줄러가 존재하는 하드웨어에 대해 결정을 내립니다. 그리고 제공자의 호스트 커널 자체에서는 vCPU 스레드의 캐시 인식 배치가 테넌트가 아닌 제공자의 이득이 됩니다. 캐시 레이아웃은 아키텍처에 따라서도 다르며, 이는 Arm VPS와 x86 VPS를 비교할 때 고려해야 할 또 하나의 변수입니다.

게스트 내부에서 캐시 동작을 측정하는 것은 베어메탈보다 어렵습니다. 하이퍼바이저가 PMU (performance monitoring unit)를 게스트에 노출하지 않기 때문에 perf stat -e cache-misses은 종종 <not supported>을 보고합니다. 대신 자신의 애플리케이션 처리량과 지연 시간을 측정하고, 두 실행 결과 사이의 전환 스위치로 debugfs 설정을 사용하십시오.

커널에 CONFIG_SCHED_CACHE가 포함되어 있는지 확인하기

uname -r
grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r) || echo 'not set in this build'
sudo ls /sys/kernel/debug/sched/ | grep -i llc

CONFIG_SCHED_CACHE=y는 커널이 해당 옵션을 포함하여 빌드되었음을 의미합니다. # CONFIG_SCHED_CACHE is not set이라고 적힌 줄은 해당 버전에서 옵션이 존재하지만 배포판에서 비활성화했음을 뜻합니다. 아무런 출력도 나오지 않는다면 보통 커널이 해당 옵션이 도입되기 이전 버전임을 의미하며, uname -r 명령어로 이를 확인할 수 있습니다. 일부 최소화된 클라우드 이미지에는 /boot/config-* 파일이 없으며, 이 경우 zcat /proc/config.gz을 대신 읽어야 합니다. 이는 커널이 CONFIG_IKCONFIG_PROC 옵션으로 빌드된 경우에만 작동합니다.

ls 줄은 기능이 컴파일되어 포함된 경우 llc_* 튜닝 값을 출력합니다. CONFIG_SCHED_CACHE=y 상태에서 아무것도 출력되지 않는다면, 먼저 sudo mount -t debugfs none /sys/kernel/debug 명령어로 debugfs를 마운트하십시오.

기능을 켜고 껐을 때의 워크로드를 비교하려면, 나중에 원래대로 되돌려야 하므로 현재 값을 먼저 기록해 두십시오:

sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance
sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'

벤치마크를 실행한 뒤, 기록해 둔 값을 다시 입력하고 벤치마크를 한 번 더 실행하십시오. debugfs에 쓴 값은 재부팅 시 유지되지 않으며, 이는 테스트 과정에서 의도한 동작입니다.

배포판 커널은 언제 7.2 버전을 지원합니까

메인라인 커널이 곧바로 VPS의 부팅 커널이 되는 것은 아닙니다. uname -r에 있는 버전은 사용 중인 배포판에서 제공하는 것이며, 각 배포판은 메인라인 릴리스를 서버에 적용하기까지 고유한 경로를 거칩니다.

Fedora는 지원 기간 중에 안정화 릴리스를 새로운 메인라인 커널로 재기반(rebase)합니다. 따라서 sudo dnf upgrade --refresh을 실행하고 재부팅하는 것만으로 모든 과정이 완료되며, 일반적으로 사용자가 새로운 커널을 가장 먼저 시도해 볼 수 있는 환경입니다. 이러한 주기는 VPS에서 Fedora Server 사용하기를 선택할 때 고려해야 할 요소 중 하나입니다.

Ubuntu는 6개월마다 새로운 릴리스를 내놓을 때마다 새 커널을 포함하며, 이후 HWE(hardware enablement) 스택을 통해 이전 LTS(long term support) 릴리스로 해당 커널을 이식합니다. 2026년 8월 기준으로, Ubuntu 24.04 LTS는 여전히 2024년 4월의 6.8 버전을 GA 커널로 설치하지만, HWE 스택은 2025년 8월에 6.14로, 2026년 2월에 6.17로 이동했습니다. 이것이 현실적인 시간표입니다. 2026년 8월의 메인라인 릴리스는 약 1년 뒤에 LTS HWE 스택에 도달합니다.

apt-cache policy linux-generic-hwe-24.04
sudo apt install --install-recommends linux-generic-hwe-24.04

Debian stable은 릴리스 수명 동안 하나의 커널 버전을 유지하며, 더 최신 버전은 패키지 단위로 선택할 수 있는 backports를 통해 제공합니다.

echo 'deb http://deb.debian.org/debian trixie-backports main' | sudo tee /etc/apt/sources.list.d/backports.list
sudo apt update
sudo apt install -t trixie-backports linux-image-amd64

이러한 작업 후에는 재부팅을 수행하고 uname -r 및 앞서 언급한 grep로 확인해야 합니다. 새로운 커널은 실행 중에 바로 로드할 수 없습니다. VPS에서의 라이브 커널 패치는 실행 중인 커널의 개별 함수 코드를 교체하는 방식이며, 구조체 레이아웃을 변경하거나 debugfs 파일을 추가할 수는 없습니다. 캐시 인식 스케줄링은 mm_struct에 필드를 추가해야 하므로 구조체 레이아웃을 변경하는 작업에 해당하며, 따라서 반드시 새로운 커널로 부팅해야만 적용됩니다.

두 가지 실질적인 후속 조치가 필요합니다. 새로운 커널이 부하를 안정적으로 처리할 때까지 이전 커널로 부팅할 수 있는 상태를 유지하십시오. 이것이 VPS에서 부팅 커널 고정하기가 필요한 이유입니다. 또한 /boot를 모니터링하십시오. 커널을 몇 번 업그레이드하면 작은 VPS 부팅 파티션은 금방 가득 차게 되며, 이에 대한 내용은 Ubuntu에서 오래된 커널 정리하기에서 다룹니다.

소유권에 관한 마지막 현실적인 조언입니다. KVM VPS에서 게스트 커널은 사용자의 것입니다. 사용자가 선택하고, 부팅하고, 롤백합니다. 호스트 커널은 서비스 제공자의 영역이며, 게스트 내부의 어떤 설정으로도 하이퍼바이저가 실행하는 스케줄러를 변경할 수 없습니다. 따라서 스케줄러 배치에 관한 릴리스 노트는 사용자에게는 절반의 이야기일 뿐이며, 사용자가 제어할 수 있는 것은 게스트 측면뿐입니다.

이 페이지의 출처

• 2026년 8월 16일 릴리스 날짜 및 스케줄러 외 변경 사항에 대한 kernelnewbies.org의 7.2 변경 로그 요약.
• debugfs 튜닝 가능 항목, 프로세스별 선호도 메커니즘, 보고된 벤치마크 수치에 대한 lwn.net/Articles/1041668 및 lwn.net/Articles/1058288의 캐시 인식 스케줄링 시리즈 관련 LWN 보도.
• 캐시 인식 로드 밸런싱이 NUMA 노드 내에 하나 이상의 LLC를 필요로 한다는 규칙에 대한 "sched/cache: Introduce sched_cache_present" 패치(토폴로지에 따라 기능을 제한함).

이전 릴리스에 대해서는 Linux 커널 7.1의 변경 사항을 참조하십시오. 버전 번호의 유래에 대해서는 Linux 커널 역사 타임라인을 참조하십시오.

FAQ

Does cache aware scheduling in Linux 7.2 make a VPS faster?

Usually not by itself. The feature only activates when a NUMA node reports more than one last level cache, and a typical KVM guest is not shown that layout, so the code never engages. Where it does engage, the guest is still scheduled twice: your kernel picks a vCPU, and the host kernel decides which physical core that vCPU thread runs on, so a guest side cache decision can be undone by the host. Run cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u in your guest. One line covering every vCPU means there is nothing for the feature to arrange.

How do I check whether my kernel has CONFIG_SCHED_CACHE?

Run grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r). CONFIG_SCHED_CACHE=y means it is built in, # CONFIG_SCHED_CACHE is not set means your distribution disabled it, and no output means the kernel is older than the option. If the image has no /boot/config-* file, try zcat /proc/config.gz, which exists only on kernels built with CONFIG_IKCONFIG_PROC. You can confirm at runtime with sudo ls /sys/kernel/debug/sched/ | grep -i llc, which lists the llc_* tunables when the feature is present.

How do I turn cache aware scheduling off without rebooting?

Write 0 to the tolerance knob: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. That disables the feature at runtime, which makes it a clean A/B switch for a benchmark. Read the current value first with sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance and write it back afterwards, because defaults vary between builds. Nothing written to debugfs survives a reboot. If cat reports No such file or directory, your kernel does not have the feature compiled in and there is nothing to turn off.

When will Ubuntu or Debian ship a 7.2 based kernel?

Fedora rebases stable releases onto new mainline kernels, so it arrives there first through a normal dnf upgrade and a reboot. Ubuntu ships new kernels with each six month release and carries them to the previous LTS through the HWE stack, and the historical gap is close to a year: as of August 2026 the 24.04 LTS HWE stack is on 6.17 from February 2026 while its GA kernel is still 6.8. Debian stable keeps one kernel for the release and offers newer ones through trixie-backports, which you install per package with apt install -t trixie-backports linux-image-amd64.