CXL 메모리 티어링, 커널은 어디까지 왔나 — DAMON이 머지한 것과 숫자가 재지 않은 것

들어가며 — CXL 이야기에서 커널이 맡은 부분
커널이 페이지를 옮기는 두 가지 방법
2026년 7월 기준, mainline에 실제로 들어간 것
4.43%라는 숫자 — 그리고 그게 재지 않은 것
25%라는 숫자 — 그리고 그게 사실 티어링이 아니라는 것
94%라는 숫자 — 조건이 없는 숫자
진짜 문제는 알고리즘이 아니라 파라미터다
아직 해결되지 않은 것들
그래서, 당신은 지금 이걸 켜야 하나
마치며
참고 자료

들어가며 — CXL 이야기에서 커널이 맡은 부분

CXL 하드웨어 이야기는 Meta의 Vistara 브리지 칩 편에서 한 번 다뤘습니다. 은퇴한 DDR4를 CXL로 되살려 두 번째 메모리 계층으로 쓴다는, 하이퍼스케일의 종단 배치 보고였습니다.

그런데 칩이 꽂혀 있다는 것과 그게 값을 한다는 건 다른 얘기입니다. CXL 메모리는 운영체제에 CPU 없는 NUMA 노드로 보일 뿐이고, 어떤 페이지가 뜨겁고 어떤 페이지가 식었는지 판단해 실제로 옮기는 일은 전부 커널이 합니다. 이 판단이 틀리면 CXL은 그냥 느린 램입니다.

그래서 이 글은 하드웨어가 아니라 그 위에서 도는 코드를 봅니다. 2026년 7월 현재 리눅스 mainline에 무엇이 실제로 들어가 있는지를 커널 소스로 직접 확인하고, 이 분야에서 인용되는 숫자들이 원본 출처에서 정확히 무엇을 재고 무엇을 재지 않았는지 따라가 봅니다. 결론부터 말하면, 들어간 것은 부품이고 정책은 아직 당신 몫이며, 숫자들은 크기가 클수록 방법론이 적게 붙어 있습니다.

커널이 페이지를 옮기는 두 가지 방법

먼저 지형입니다. 티어링된 메모리에서 페이지를 옮기는 mainline 메커니즘은 크게 둘입니다.

첫째, NUMA balancing 티어링 모드(NUMAB-2). 접근 확인용 페이지 폴트(prot_none)로 뜨거운 페이지를 찾고, 프로세스 자신의 컨텍스트에서 승격을 수행합니다. 즉 승격 작업이 애플리케이션의 실제 일과 같은 스레드에서 일어납니다. 강등은 reclaim 기반으로 kswapd나 direct reclaim이 처리합니다.

둘째, DAMON과 그 위의 DAMOS. DAMON은 커널 스레드를 띄워 메모리 접근을 5ms마다 샘플링하고, 결과를 100ms마다 유저스페이스로 넘깁니다. 일반적인 시스템에서 오버헤드는 0.1% 미만이라고 DAMON 창시자 SeongJae Park이 LSFMM+BPF 2026에서 발표했습니다. 5.15에 처음 머지됐습니다. DAMOS는 그 관찰 결과에 동작을 붙이는 층이고, 티어링에 쓰이는 동작이 migrate_hot(승격)과 migrate_cold(강등)입니다. 핵심 차이는 DAMOS가 비동기 워커 스레드에서 돈다는 점입니다.

이 차이가 나중에 숫자로 돌아옵니다.

2026년 7월 기준, mainline에 실제로 들어간 것

발표 자료나 뉴스가 아니라 커널 소스를 직접 확인했습니다. 아래는 각 기능이 처음 나타나는 태그를 include/linux/damon.h와 문서에서 확인한 결과입니다.

6.11    DAMOS_MIGRATE_HOT / DAMOS_MIGRATE_COLD
        (v6.10에 없음 → v6.11에 등장. SK hynix: Hyeongtak Ji, Honggyu Kim, 2024-06-14)
        HMSDK의 CXL 용량 확장용. 임계값은 사람이 손으로 박는 정적 값.

6.16    node_mem_used_bp / node_mem_free_bp 쿼터 목표
        (자가 튜닝 티어링, 일명 TPP-DAMON. SeongJae Park)

6.17    damos->migrate_dests — 목적지 노드 여러 개 + 가중치
        (Micron: Bijan Tabatabai. 가상 주소 공간 전용)

6.19    node_memcg_used_bp / node_memcg_free_bp
        (cgroup 단위 티어링. Meta 협업)

7.2-rc1 node_eligible_mem_bp
        (Micron: Ravi Jonnalagadda. 아직 정식 릴리스된 커널에는 없음)

여기서 두 가지를 짚어야 합니다.

첫째, "그냥 되는" 티어링 커널 모듈은 없습니다. v7.2-rc3의 mm/damon/Kconfig에서 "tier"라는 문자열은 0번 나옵니다. 빌드되는 DAMON 모듈은 DAMON_RECLAIM, DAMON_LRU_SORT, DAMON_STAT 셋뿐이고 mm/damon/ 아래에 tiering.c는 없습니다. 즉 mainline이 주는 건 부품(쿼터 목표 metric, 마이그레이션 동작, 목적지 가중치)이고, 그걸 조립해 정책으로 만드는 일은 유저스페이스 몫입니다.

이건 사고가 아니라 계획대로입니다. 자가 튜닝 티어링 RFC 커버레터에서 저자 본인이 쿼터 목표 metric 부분을 먼저 올리고 티어링 모듈 부분은 "나중에" 올리겠다고 적었습니다. 모듈 쪽은 2계층만 가정하고 노드 주소 범위를 사용자가 직접 넣어야 하는, 완성형과 거리가 먼 상태라는 게 이유였습니다. 그 "나중에"는 2026년 7월 현재까지 오지 않았습니다.

그래서 오늘 이걸 굴리려면 발표 슬라이드에 나온 것처럼 damo 명령을 직접 짜야 합니다.

damo start \
  --numa_node 0 --monitoring_intervals_goal 4% 3 5ms 10s \
      --damos_action migrate_cold 1 --damos_access_rate 0% 0% \
      --damos_apply_interval 1s \
      --damos_quota_interval 1s --damos_quota_space 200MB \
      --damos_quota_goal node_mem_free_bp 0.5% 0 \
      --damos_filter reject young \
  --numa_node 1 --monitoring_intervals_goal 4% 3 5ms 10s \
      --damos_action migrate_hot 0 --damos_access_rate 5% max \
      --damos_apply_interval 1s \
      --damos_quota_interval 1s --damos_quota_space 200MB \
      --damos_quota_goal node_mem_used_bp 99.7% 0 \
      --damos_filter allow young \
      --damos_nr_quota_goals 1 1 --damos_nr_filters 1 1 \
  --nr_targets 1 1 --nr_schemes 1 1 --nr_ctxs 1 1

노드 0(DRAM)에서는 식은 페이지를 강등하되 여유 공간 0.5%를 목표로, 노드 1(CXL)에서는 뜨거운 페이지를 승격하되 DRAM 사용률 99.7%를 목표로 돌리는 구성입니다. 0.5%와 99.7%가 살짝 겹치도록 잡아 승격과 강등이 서로 멈추지 않게 하는 게 설계 의도이고, 커버레터는 이 두 값을 기본 권장값으로 제안합니다. 나쁘지 않은 인터페이스지만, 이걸 "그냥 된다"고 부르긴 어렵습니다.

둘째, CONFIG_DAMON은 기본값이 아닙니다. 2025년 5월 SeongJae Park이 주요 배포판들이 이미 DAMON을 빌드 활성화하고 있고 커널 패키지 크기가 약 0.1%만 늘어난다는 근거로 기본 활성화 패치를 올렸고, 6.16-rc1 머지 윈도에 들어갔습니다. 그리고 2025년 6월 10일 Linus Torvalds가 되돌렸습니다. 커밋 aef17cb3d3c4의 본문은 한 줄입니다 — "No, we don't make random features default to being on."

v7.2-rc3의 mm/damon/Kconfig를 확인해 보면 config DAMON에는 지금도 default y가 없습니다. 되돌림은 그대로 유지됐습니다.

4.43%라는 숫자 — 그리고 그게 재지 않은 것

자가 튜닝 티어링(6.16)에 붙어 다니는 숫자가 4.42%입니다. 원본 RFC 커버레터(SeongJae Park, 2025-03-19)를 읽어 보면 조건이 전부 적혀 있습니다.

측정 환경. DRAM 계층 250 GiB, CXL 계층 50 GiB를 각각 NUMA 노드 0과 1로 노출한 머신. 커널은 v6.13에 2025-03-15 mm 트리의 DAMON 패치 전부와 해당 시리즈를 얹고, 애플리케이션의 전통적 NUMA 최적화가 끼어들지 않도록 mempolicy() 시스템 콜을 무시하도록 고쳤습니다. 워크로드는 DCPerf의 Taobench 변형으로 메모리 크기 340 GiB, 워밍업 2,500초, 측정 1,440초, RSS는 워밍업 중 270 GiB까지 자랍니다. 각 구성마다 5회 반복.

결과 표(커버레터 원문).

Config         Score   Stdev   (%)     Normalized
Baseline       1.6165  0.0319  1.9764  1.0000
Numab_tiering  1.4976  0.0452  3.0209  0.9264
DAMON_tiering  1.6881  0.0249  1.4767  1.0443

직접 계산해 보면 1.6881 나누기 1.6165는 1.0443이니 DAMON 티어링은 4.43% 개선, 1.4976 나누기 1.6165는 0.9264이니 NUMAB-2는 7.36% 저하입니다. (커버레터 요약부는 4.42%와 7.34%로 적고 있는데, 자기 표에서 나오는 값은 4.43%와 7.36%입니다. 1년 뒤 LSFMM 슬라이드까지 "~4.42%"가 그대로 실려 다닙니다. 사소하지만, 인용되는 숫자가 원 표를 다시 계산해 본 사람 손을 거치지 않는다는 뜻이기도 합니다.)

여기까지는 좋은 소식처럼 들립니다. 이제 같은 커버레터가 스스로 적어 둔 캐비엇을 봅시다.

워크로드가 원래는 아무 차이도 못 만들었습니다. 저자의 서술을 그대로 옮기면, Taobench는 접근 패턴이 매우 정적이어서 RSS의 약 13%만 처음부터 끝까지 자주 접근됐고, 그 결과 설계와 구현이 무엇이든 승격은 의미 있는 성능 차이를 만들지 못했습니다. 그래서 저자는 커널을 고쳐서 1분에 한 번씩 뜨거운 페이지를 최대 10 GiB 강등하고 식은 페이지를 최대 10 GiB 승격시키는 훼방을 넣었습니다. 접근 패턴이 주기적으로 바뀌는 상황을 시뮬레이션하기 위해서였고, 워크로드 이름에 "modified"가 붙은 이유가 이것입니다.

즉 4.43%는 티어링이 유리하도록 인위적으로 흔든 워크로드에서 나온 값입니다. 흔들지 않은 원래 워크로드에서는 어떤 티어링 구현도 차이를 못 냈습니다.

강등은 아예 일어나지 않았습니다. 커버레터가 직접 밝히듯, 시뮬레이션용 훼방이 워크로드 시작부터 돌아 DRAM 계층 사용량이 항상 워터마크 아래에 머물렀고 그래서 모든 테스트 런에서 실제 강등이 발생하지 않았습니다. 이 표는 LRU 기반 강등과 DAMON 기반 강등을 비교하지 않습니다. 오직 NUMAB-2 승격과 DAMON 승격의 차이만 담고 있습니다.

저자 본인의 한계 서술. 커버레터에는 "Evaluation Limitations" 절이 따로 있고, 관점에 따라 이 변형 Taobench가 그림을 너무 왜곡한 것처럼 보일 수 있으며 더 현실적인 워크로드나 더 공정한 마이크로벤치마크로 평가하는 편이 낫겠다고 적혀 있습니다. 저자가 자기 숫자에 대해 이보다 더 정직하기는 어렵습니다.

그리고 표준편차. 점수 대비 표준편차가 1.48%에서 3.02%입니다. 4.43%는 그 위에 있긴 하지만 압도적으로 위는 아닙니다.

진짜 흥미로운 건 다른 줄입니다. 같은 테스트에서 NUMAB-2, 즉 커널에 이미 들어 있는 기존 티어링 기능은 성능을 7.36% 떨어뜨렸습니다. 저자는 NUMAB-2의 동기적 승격이 Taobench의 실제 작업 진행을 막았기 때문이라고 추정합니다. 앞에서 짚은 "프로세스 컨텍스트에서 승격"이 여기서 값을 치른 겁니다.

이 표를 한 줄로 요약하면 이렇습니다 — 티어링을 켤 이유를 억지로 만들어 준 워크로드에서, 새 방식은 4.43% 벌었고 기존 방식은 7.36% 잃었습니다.

25%라는 숫자 — 그리고 그게 사실 티어링이 아니라는 것

6.17의 다중 목적지 마이그레이션에는 25%가 붙어 다닙니다. 원본 커버레터(Bijan Tabatabai, Micron, 2025-07-02)를 보면 이것도 조건이 다 적혀 있고, 앞의 이야기와는 성격이 완전히 다릅니다.

측정 환경. 128코어 256스레드 AMD CPU, 로컬 DDR 대역폭 72 GB/s, CXL 대역폭 26 GB/s. 워크로드는 대역폭 집약적인 embedding reduction 애플리케이션으로, 반복마다 같은 할당을 재사용하고 반복별 소요 시간을 보고합니다.

진행. 처음엔 시스템 대역폭 사용률이 낮으니 인터리브 가중치를 1대 0으로 두고 전부 로컬 메모리에 할당합니다. 워크로드가 시작되면 로컬 대역폭이 포화되고, 이때 가중치를 3대 1로 바꿔 DAMON이 데이터를 옮기게 합니다. 반복 시간은 7,600ms대에서 5,630ms대로 떨어졌고 커버레터는 이를 약 25% speedup이라고 적습니다.

여기서 중요한 전환. 이건 "뜨거운 건 빠른 계층, 식은 건 느린 계층"이 아닙니다. 정반대로 뜨거운 데이터를 일부러 느린 CXL에 얹어서 두 계층의 대역폭을 합산하는 겁니다. 용량 티어링이 아니라 대역폭 인터리빙입니다.

숫자가 맞아떨어지는지 직접 확인해 봤습니다. 72 더하기 26은 98이고, 98 나누기 72는 1.361이니 대역폭 병목이라면 시간은 0.735배가 돼야 합니다. 7,620ms 곱하기 0.735는 약 5,600ms이고 실측은 약 5,634ms입니다. 오차 1% 안쪽으로 들어맞습니다. 가중치 3대 1도 대역폭 비율 72대 26(약 2.8대 1)에 붙어 있습니다. 즉 이 25%는 대역폭 합산으로 설명이 되며, 그 이상도 이하도 아닙니다. 순수하게 대역폭에 묶인 워크로드가 아니라면 이 이득은 나오지 않습니다.

그리고 가장 정직해야 할 부분. 가중치를 1대 0에서 3대 1로 바꾼 건 사람입니다. 정확히 대역폭이 포화된 그 순간에요. 커버레터는 이 점을 숨기지 않습니다 — 이 패치 세트는 데이터를 어떻게 인터리브할지 바꾸는 메커니즘을 추가할 뿐이고, 가중치가 얼마여야 하는지라는 정책은 유저스페이스에 남긴다고 명시합니다. 그리고 시스템 대역폭 사용률이나 접근 지연을 모니터링해 가중치를 조율하는 유저스페이스 프로그램을 만들고 있지만 아직 공개할 준비가 안 됐다고 적습니다.

그 루프를 닫는 조각이 앞의 타임라인에 있던 node_eligible_mem_bp입니다. 스킴의 접근 패턴에 매칭되는 메모리 중 특정 노드에 있는 비율을 basis point로 재는 metric이고, 이걸 목표로 걸면 "뜨거운 데이터의 60%는 DRAM에, 40%는 CXL에" 같은 분포를 쿼터 오토튜너가 알아서 유지합니다. 커밋 9138e27a3bc3(Ravi Jonnalagadda, Micron)이 그 구현입니다.

주목할 점 셋. 첫째, 이 커밋은 저자 날짜가 2026-04-28이고 커밋 날짜가 2026-05-29입니다. 7.1-rc1이 2026-04-26에 나왔으니 이건 7.1을 놓쳤고, 실제로 DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP는 v7.0에도 v7.1에도 없고 v7.2-rc1에 처음 나타납니다. v7.2는 아직 정식 릴리스가 아니므로(현재 최신 태그가 v7.2-rc3입니다), 오늘 기준 이 기능이 들어간 정식 커널은 아직 없습니다. (LWN 기사는 이 기능이 7.1-rc1에 머지됐다고 적었지만, 발표자 본인 슬라이드는 "7.1-rc1 이후 mm-new에 머지"라고 적고 있고 소스가 슬라이드 쪽 손을 들어 줍니다. 7.1-rc1에 들어간 건 쿼터 목표 튜너 알고리즘 쪽입니다.)

둘째, 이 커밋에는 성능 숫자가 하나도 없습니다. "Testing Results" 절이 있긴 한데 내용은 2노드 이종 메모리 시스템에서 기능 검증을 했다는 것, TEMPORAL 튜너는 목표 분포로 빨리 수렴하고 CONSIST 튜너는 더 느리게 수렴한다는 것, 목표 도달 시간은 워크로드 강도에 따라 달라진다는 것뿐입니다. 수렴 동작 보고이지 speedup 보고가 아닙니다.

셋째, CONFIG_DAMON_PADDR이 필요합니다. 물리 주소 공간에서만 동작합니다. 반면 6.17의 가중치 인터리빙은 가상 주소 공간 전용입니다 — 폴리오가 VMA 안에서 매핑된 오프셋으로 목적지 노드를 정하는데, 물리 주소 스킴에서 그걸 알아내려면 비싼 rmap 순회가 필요하기 때문입니다. 즉 메커니즘과 그 자동 튜닝 목표가 서로 다른 주소 공간에 살고 있습니다.

정리하면, 25%는 진짜지만 사람이 손으로 스위치를 올려서 얻은 값이고, 그 스위치를 자동으로 올려 줄 물건은 1년 뒤에야 -rc에 도착했으며 아직 성능 숫자가 붙지 않았습니다.

94%라는 숫자 — 조건이 없는 숫자

LSFMM+BPF 2026에서 가장 큰 숫자는 94%였습니다. TPP-DAMON이 단일 스레드로는 너무 느려 다중 스레드 모델로 옮겼고, llama.cpp 벤치마크에서 94% 개선을 낸다는 내용입니다. SK hynix가 한 작업입니다.

발표자 본인이 공개한 슬라이드 원본을 받아 확인해 보면, 해당 슬라이드는 이렇게 생겼습니다 — 제목 "Multi-thread Tiering (SK hynix)", 불릿 셋: 서브리전별 DAMON 워커 스레드, 뜨거운/식은 페이지 찾기 가속, 마이그레이션 가속. 그리고 마지막 불릿 "Achieves ~94% llama.cpp speedup".

그게 전부입니다. 어떤 하드웨어인지, 어떤 모델인지, 무엇 대비인지, 몇 번 돌렸는지 아무것도 없습니다. 이 숫자의 조건을 담은 공개 커버레터를 저는 찾지 못했습니다. DAMON 프로젝트 자체 뉴스 목록에도 이 항목은 없습니다. LWN 기사가 같은 94%를 전하고 있지만 그건 같은 발표를 받아적은 것이므로 독립적인 확인이 아닙니다.

이걸 "가짜"라고 말하는 게 아닙니다. 다만 대조는 해 둘 만합니다. 4.43%에는 하드웨어 스펙, 워크로드 파라미터, 5회 반복, 표준편차 컬럼, 그리고 저자가 직접 쓴 한계 절이 붙어 있습니다. 94%에는 불릿 하나가 붙어 있습니다. 이 분야에서 숫자의 크기와 방법론의 양은 대체로 반비례합니다. 그리고 슬라이드를 계속 읽으면 이렇게 적혀 있습니다 — TPP-DAMON은 긍정적 테스트 결과가 "비공개로 공유"됐고(privately shared), 더 이상의 활발한 개발 계획은 없으며 지원 모드에 들어갔습니다.

즉 커널 티어링의 간판 자동 튜닝 모듈은 공개 성능 근거 없이 유지보수 모드로 넘어갔고, 개발 역량은 NUMA-TPP-DAMON이라는 다음 물건으로 옮겨 갔습니다. 그건 슬라이드 표현으로 "브레인스토밍 수준의 초기 기획"입니다.

진짜 문제는 알고리즘이 아니라 파라미터다

왜 이 커뮤니티가 이렇게까지 자동 튜닝에 매달리는지는 위스콘신 대학 연구진의 논문이 잘 설명합니다. From Good to Great: Improving Memory Tiering Performance Through Parameter Tuning(Kanellis 등, arXiv:2504.18714, 2025-04-25)의 초록은 이렇게 말합니다 — 기존 티어링 솔루션은 휴리스틱과 미리 정해 둔 임계값으로 배치·이주를 결정하는데, 그래서 워크로드와 하드웨어에 적응하지 못하고 최적 이하로 동작한다.

연구진은 베이지안 최적화로 기존 티어링 시스템(HeMem과 SK hynix의 HMSDK)의 파라미터를 탐색했고, 값을 제대로 잡으면 같은 시스템의 기본 설정 대비 2배, 당시 최신 티어링 시스템 대비 1.56배 성능이 나온다고 보고합니다.

이 문장을 앞의 4.43%와 나란히 놓으면 그림이 선명해집니다. 알고리즘을 바꿔서 얻는 게 한 자릿수 퍼센트인데, 같은 알고리즘의 파라미터를 제대로 잡으면 2배가 나옵니다. 티어링에서 값을 결정하는 건 메커니즘이 아니라 튜닝입니다. 그리고 기본 설정은 절반을 버리고 있습니다.

동시에 이건 나쁜 소식이기도 합니다. 그 2배를 얻는 방법이 베이지안 최적화, 즉 워크로드마다 비싼 탐색을 돌리는 것이기 때문입니다. 프로덕션에서 워크로드마다 파라미터 스윕을 돌릴 여력이 있는 조직은 많지 않습니다. 커널이 하려는 자가 튜닝은 바로 이 탐색을 온라인 피드백 루프로 대체하려는 시도이고, 6.16의 사용률·여유공간 목표부터 7.2-rc1의 분포 목표까지가 그 궤적입니다. 아직 도착하지 않았을 뿐입니다.

아직 해결되지 않은 것들

발표에서 나온 열린 문제들이 지금 이 기술의 성숙도를 가장 정확하게 말해 줍니다.

DAMON은 누가 접근했는지 모릅니다. 자가 튜닝 티어링 커버레터가 명시하듯 이 설계는 CPU NUMA 노드가 하나인 경우만 가정합니다. DAMON이 접근 정보의 출처를 알 수 없기 때문에, CPU NUMA 노드가 여럿인 시스템에 적용하는 건 복잡해진다고 저자가 직접 적었습니다. 2소켓 서버가 흔하다는 걸 생각하면 이건 작은 단서가 아닙니다.

DAMON과 NUMA balancing이 같은 비트를 놓고 다툽니다. 둘 다 page-idle 비트로 접근을 확인하기 때문에, 서로가 유발한 폴트를 상대방이 "측정"하게 됩니다. 발표에서 나온 후보안은 빌드 타임 배타(둘 중 하나만 커널에 넣기), 런타임 격리(한 번에 하나만 활성), 부분 격리, 그리고 그냥 서로 간섭하게 두기였습니다. Park의 제안은 필요한 정리 작업이 끝나면 첫 구현은 빌드 타임 배타를 쓰거나 아예 문제를 무시하자는 쪽이었습니다. 배타로 가면 배포판이 둘 중 하나를 골라야 하는 곤란한 처지에 놓입니다. 세션에서 Davidlohr Bueso가 여러 층이 메모리 배치 결정을 두고 서로 싸우는 문제를 우려한 것도 같은 맥락입니다.

다음 세대는 아직 아이디어입니다. NUMA-TPP-DAMON — 티어링을 NUMA 배치의 특수한 경우로 일반화해서 CPU·GPU 등 여러 접근자(accessor)마다 승격 경로를 따로 돌리자는 구상은 브레인스토밍 단계이고, 접근자별 모니터링이라는 난제가 앞에 있습니다.

그리고 문서. node_eligible_mem_bp는 v7.2-rc3의 include/linux/damon.h에는 있지만 DAMON 설계 문서의 쿼터 목표 metric 목록에는 아직 없습니다. 문서가 늦는 건 흔한 일이지만, 이 기능이 얼마나 갓 도착한 물건인지를 보여 주는 표시이긴 합니다.

그래서, 당신은 지금 이걸 켜야 하나

켤 만한 경우

서버가 코어가 아니라 메모리 용량에 묶여 있고, 워크로드 메모리의 상당 부분이 실제로 식어 있다. (Meta가 Vistara 논문에서 보고한 fleet 43.7%가 이 상태였습니다.)
워크로드가 대역폭에 묶여 있고 CXL 대역폭을 합산해서 얻을 게 있다. 이 경우엔 용량 티어링이 아니라 가중치 인터리빙을 봐야 하고, 위 25% 사례의 산수를 당신 하드웨어 숫자로 다시 해 보면 상한이 바로 나옵니다.
파라미터를 실제 워크로드로 튜닝할 여력이 있다. 위 논문대로라면 여기가 2배가 있는 자리입니다.
CPU NUMA 노드가 하나다.

아직 아닌 경우

접근 패턴이 정적이다. 4.43% 실험의 원래 Taobench가 그랬고, 결과는 어떤 구현으로도 의미 있는 차이가 없었습니다. 티어링은 뜨거움과 차가움이 시간에 따라 바뀔 때 값을 합니다. 안 바뀌면 옮길 이유가 없습니다.
"켜면 알아서 되는" 것을 기대한다. mainline에 티어링 모듈은 없고, damo 명령줄과 몇 개의 손으로 고른 상수가 당신 것입니다.
2소켓 이상이다. 설계가 아직 그 경우를 가정하지 않습니다.
지연에 민감한 서비스인데 여유가 빠듯하다. 강등이 틀리면 그 페이지의 다음 접근은 CXL 지연을 그대로 먹습니다.
NUMAB-2를 켜면 될 거라고 생각한다. 위 표에서 그건 7.36% 손해였습니다. 적어도 그 워크로드에서는요.

무엇을 하든 순서는 하나입니다 — 당신 워크로드의 접근 패턴을 먼저 재세요. 다행히 그건 이제 쉽습니다. DAMON_STAT이 6.17에 들어갔고 Debian 커널에서 빌드 활성화돼 있습니다. 페이지의 몇 퍼센트가 몇 시간째 안 읽히는지 모른 채 티어링을 켜는 건, 위 실험이 정확히 보여 주듯 아무것도 아닌 일에 마이그레이션 오버헤드를 내는 것입니다.

마치며

정리하면 이렇습니다. 리눅스 mainline은 2024년 6.11부터 2026년 7.2-rc1까지 CXL 티어링 부품을 꾸준히 받아 왔고, 그 부품들은 대부분 메모리를 파는 회사들(SK hynix, Micron)과 메모리에 돈이 묶인 회사(Meta)가 직접 쓴 코드입니다. 부품 자체는 잘 설계돼 있습니다.

다만 정직하게 말하면, 오늘 mainline에는 켜면 되는 티어링 모듈이 없고, CONFIG_DAMON은 기본으로 꺼져 있으며, 자동 튜닝의 마지막 조각은 아직 정식 릴리스에 들어가지 않았고, 간판 모듈은 공개 성능 근거 없이 지원 모드로 넘어갔습니다. 인용되는 숫자 중 가장 잘 문서화된 것은 4.43%이고 그것도 워크로드를 인위적으로 흔들어야 나왔으며, 가장 큰 숫자인 94%에는 조건이 없습니다.

CXL이 과대 선전돼 왔다는 말은 흔합니다. 커널 쪽에서 본 그림은 조금 다릅니다 — 여기서 진행은 느리지만 실재하고, 무엇보다 작업하는 사람들 스스로가 자기 숫자에 대해 대단히 정직합니다. 커버레터에 "이 워크로드는 그림을 너무 왜곡한 것처럼 보일 수 있다"고 적고, 슬라이드에 "결과는 비공개로 공유됐다"고 적는 사람들입니다. 과장은 대체로 이 코드를 쓰는 사람들이 아니라 그걸 요약해 나르는 층에서 붙습니다.

그러니 CXL 티어링을 검토한다면, 벤더 자료 대신 커버레터를 읽으십시오. 거기에는 숫자와 함께 그 숫자가 재지 않은 것들의 목록이 이미 적혀 있습니다.