가이드

작성자 Matt Connor 2026-08-18 · 업데이트됨 2026-10-06

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

Q: 커널에 CONFIG_SCHED_CACHE가 포함되어 있는지 어떻게 확인합니까?

grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r)을 실행하십시오. CONFIG_SCHED_CACHE=y은 기능이 내장되어 있음을 의미하고, # CONFIG_SCHED_CACHE is not set은 배포판에서 해당 기능을 비활성화했음을 의미하며, 아무런 출력도 없다면 커널 버전이 해당 옵션보다 낮다는 뜻입니다. 이미지에 /boot/config-* 파일이 없다면 zcat /proc/config.gz을 시도하십시오. 이 파일은 CONFIG_IKCONFIG_PROC로 빌드된 커널에만 존재합니다. 런타임 시 sudo ls /sys/kernel/debug/sched/ | grep -i llc를 사용하여 확인할 수 있으며, 기능이 존재할 경우 llc_* 튜닝 가능 항목들이 나열됩니다.

Q: 재부팅 없이 캐시 인식 스케줄링을 끄려면 어떻게 해야 합니까?

허용 오차 설정값에 0를 기록하십시오: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. 이 작업은 런타임에 기능을 비활성화하므로 벤치마크를 위한 깔끔한 A/B 테스트 스위치 역할을 합니다. 빌드마다 기본값이 다르므로 먼저 sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance으로 현재 값을 읽어둔 뒤 나중에 다시 기록하십시오. debugfs에 기록된 내용은 재부팅 시 유지되지 않습니다. cat이 No such file or directory을 반환한다면, 커널에 해당 기능이 컴파일되어 있지 않으므로 끌 것도 없다는 의미입니다.

Q: Ubuntu나 Debian은 언제 7.2 기반 커널을 배포합니까?

Fedora는 안정적인 릴리스를 새로운 메인라인 커널로 리베이스하므로, 일반적인 dnf upgrade와 재부팅을 통해 가장 먼저 적용됩니다. Ubuntu는 6개월마다 새로운 커널을 배포하고 HWE 스택을 통해 이전 LTS 버전으로 이식합니다. 과거 사례를 보면 그 간격은 약 1년 정도입니다. 2026년 8월 기준으로 24.04 LTS HWE 스택은 2026년 2월의 6.17 커널을 사용 중이며, GA 커널은 여전히 6.8입니다. Debian stable은 릴리스당 하나의 커널을 유지하며, 더 최신 커널은 trixie-backports을 통해 제공하고 apt install -t trixie-backports linux-image-amd64을 사용하여 패키지별로 설치할 수 있습니다.

Linux 커널 7.2에 도입된 CONFIG_SCHED_CACHE 기능이 VPS 환경에서 실제 성능 향상을 제공하는지 분석합니다. NUMA 노드 및 LLC 구조에 따른 스케줄러 동작 변화와 가상화 환경에서의 적용 가능성을 기술적으로 검증합니다.

Linux 커널 7.2의 새로운 기능

Linux 커널 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로 지정되며, 이후의 모든 결정은 이 단일 수치를 참조합니다.

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

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

llc_aggr_tolerance은 0에서 100 사이의 값으로, 커널이 얼마나 강하게 집계(aggregate)를 수행할지 결정합니다. 0는 런타임에 캐시 인식 스케줄링 기능을 끕니다. 1은 신중한 설정입니다. RSS(상주 메모리 크기)가 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.

성능 향상이 기대되는 워크로드와 그렇지 않은 워크로드

아래 수치는 패치 시리즈와 함께 공개된 데이터로, 서버급 하드웨어에서 측정되었으며 일부는 허용 오차 범위를 공격적으로 설정한 결과입니다. 이 수치는 베어메탈 환경에서의 최적 사례를 나타낼 뿐, 귀하의 시스템에서 동일한 성능을 보장하지는 않습니다.

ChartReported gains from cache aware scheduling, server hardware, percent

label

gain_pct

hackbench, 1 group, Xeon Sapphire Rapids

30.57

schbench, 4 threads, p99 wakeup latency, Sapphire Rapids

37.78

ChaCha20 throughput, AMD Genoa, aggressive tolerance

The data behind this chart

[
  {
    "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가 하나만 보고되는 노드인 경우. 이 기능은 해당 환경에서 전혀 활성화되지 않습니다.

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

VPS 게스트가 이 설정을 확인할 수 있습니까

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

첫째, 이 기능은 토폴로지에 따라 제한됩니다. 캐시 인지 로드 밸런싱(Cache aware load balancing)은 하나의 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에 남기는 스틸 타임(steal time)을 발생시키는 것과 동일한 계층 경계입니다.

그렇다면 이 기능은 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 파일을 추가할 수는 없습니다. 캐시 인식 스케줄링(Cache aware scheduling)은 mm_struct에 필드를 추가해야 하므로 구조체 변경이 필요하며, 따라서 새로운 커널로 부팅해야만 적용됩니다.

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

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

이 페이지의 출처

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

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

FAQ

Linux 7.2의 캐시 인식 스케줄링(cache aware scheduling)이 VPS의 속도를 높여줍니까?

일반적으로 그렇지 않습니다. 이 기능은 NUMA 노드가 여러 개의 마지막 레벨 캐시(last level cache)를 보고할 때만 활성화되는데, 일반적인 KVM 게스트는 해당 레이아웃을 표시하지 않으므로 코드가 작동하지 않습니다. 기능이 작동하는 환경이라 하더라도 게스트는 두 번 스케줄링됩니다. 게스트 커널이 vCPU를 선택하면 호스트 커널이 해당 vCPU 스레드를 실행할 물리적 코어를 결정하므로, 게스트 측의 캐시 결정이 호스트에 의해 무효화될 수 있습니다. 게스트에서 cat /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list | sort -u를 실행하십시오. 모든 vCPU가 한 줄로 표시된다면, 해당 기능이 조정할 대상이 없다는 의미입니다.

커널에 CONFIG_SCHED_CACHE가 포함되어 있는지 어떻게 확인합니까?

grep -E '^CONFIG_SCHED_CACHE' /boot/config-$(uname -r)을 실행하십시오. CONFIG_SCHED_CACHE=y은 기능이 내장되어 있음을 의미하고, # CONFIG_SCHED_CACHE is not set은 배포판에서 해당 기능을 비활성화했음을 의미하며, 아무런 출력도 없다면 커널 버전이 해당 옵션보다 낮다는 뜻입니다. 이미지에 /boot/config-* 파일이 없다면 zcat /proc/config.gz을 시도하십시오. 이 파일은 CONFIG_IKCONFIG_PROC로 빌드된 커널에만 존재합니다. 런타임 시 sudo ls /sys/kernel/debug/sched/ | grep -i llc를 사용하여 확인할 수 있으며, 기능이 존재할 경우 llc_* 튜닝 가능 항목들이 나열됩니다.

재부팅 없이 캐시 인식 스케줄링을 끄려면 어떻게 해야 합니까?

허용 오차 설정값에 0를 기록하십시오: sudo sh -c 'echo 0 > /sys/kernel/debug/sched/llc_aggr_tolerance'. 이 작업은 런타임에 기능을 비활성화하므로 벤치마크를 위한 깔끔한 A/B 테스트 스위치 역할을 합니다. 빌드마다 기본값이 다르므로 먼저 sudo cat /sys/kernel/debug/sched/llc_aggr_tolerance으로 현재 값을 읽어둔 뒤 나중에 다시 기록하십시오. debugfs에 기록된 내용은 재부팅 시 유지되지 않습니다. cat이 No such file or directory을 반환한다면, 커널에 해당 기능이 컴파일되어 있지 않으므로 끌 것도 없다는 의미입니다.

Ubuntu나 Debian은 언제 7.2 기반 커널을 배포합니까?

Fedora는 안정적인 릴리스를 새로운 메인라인 커널로 리베이스하므로, 일반적인 dnf upgrade와 재부팅을 통해 가장 먼저 적용됩니다. Ubuntu는 6개월마다 새로운 커널을 배포하고 HWE 스택을 통해 이전 LTS 버전으로 이식합니다. 과거 사례를 보면 그 간격은 약 1년 정도입니다. 2026년 8월 기준으로 24.04 LTS HWE 스택은 2026년 2월의 6.17 커널을 사용 중이며, GA 커널은 여전히 6.8입니다. Debian stable은 릴리스당 하나의 커널을 유지하며, 더 최신 커널은 trixie-backports을 통해 제공하고 apt install -t trixie-backports linux-image-amd64을 사용하여 패키지별로 설치할 수 있습니다.

#linux-kernel#scheduler#releases#performance #vps