CPU 캐시 (CPU Cache)

CPU 캐시를 하드웨어 미시 구조와 커널 성능 튜닝 관점에서 함께 설명합니다. L1/L2/L3 계층과 TLB 상호작용, 인덱싱 방식(VIPT/PIPT)과 alias 이슈, 코히런시 프로토콜(MESI/MOESI/MESIF), 프리페처·교체 정책, Intel RDT(CAT/MBA), NUMA 캐시 affinity, false sharing 탐지와 perf c2c 기반 진단 절차까지 종합적으로 다룹니다.

CPU 캐시는 프로세서와 메인 메모리 사이의 속도 차이(수백 배)를 완화하기 위한 고속 SRAM 버퍼입니다. 리눅스 커널은 캐시 라인 정렬, 코히런시, TLB 관리, 프리페칭 등 다양한 수준에서 캐시를 인식하고 활용합니다. 이 페이지에서는 하드웨어 캐시의 원리부터 커널의 캐시 API, 실전 진단까지 종합적으로 다룹니다.

캐시 기본 원리

캐시 라인

캐시의 최소 전송 단위는 캐시 라인(cache line)으로, 현대 x86/ARM 프로세서에서 대부분 64바이트입니다. 메모리 주소를 캐시 라인 크기로 나눈 몫이 같은 바이트들은 항상 함께 캐시에 올라옵니다. 따라서 구조체의 핫 필드를 같은 캐시 라인에 배치하면 하나의 캐시 미스로 여러 필드를 동시에 읽을 수 있습니다.

/* include/linux/cache.h */
#ifndef L1_CACHE_BYTES
#define L1_CACHE_BYTES  (1 << L1_CACHE_SHIFT)  /* x86: 64 */
#endif

#define ____cacheline_aligned  __attribute__((__aligned__(L1_CACHE_BYTES)))

/* 핫 필드를 캐시 라인 경계에 정렬 */
struct net_device {
    char                    name[IFNAMSIZ];
    /* ... 핫 패스 필드 ... */
    unsigned long           state;
    /* 콜드 필드는 별도 캐시 라인으로 분리 */
    struct list_head        dev_list ____cacheline_aligned_in_smp;
};

공간적 / 시간적 지역성

캐시가 효과적인 이유는 프로그램의 지역성(locality) 때문입니다.

• 시간적 지역성(Temporal Locality): 최근 접근한 데이터는 곧 다시 접근될 가능성이 높습니다. 예: slab 캐시에서 자주 할당/해제되는 객체.
• 공간적 지역성(Spatial Locality): 접근한 주소 근처의 데이터도 곧 접근될 가능성이 높습니다. 예: 페이지 테이블 워크에서 연속된 PTE 읽기.

히트와 미스

캐시 히트(hit)는 요청한 데이터가 캐시에 존재하는 경우이고, 미스(miss)는 존재하지 않아 하위 메모리 계층에서 가져와야 하는 경우입니다. 미스는 세 가지로 분류됩니다:

• Compulsory (cold) miss: 데이터를 처음 접근할 때. 프리페칭으로 완화 가능.
• Capacity miss: 캐시 용량이 부족하여 이전 데이터가 축출. 더 큰 캐시나 작업 집합(working set) 축소로 완화.
• Conflict miss: 연관도(associativity)가 부족하여 같은 셋에 매핑된 라인끼리 충돌. 더 높은 연관도로 완화.

캐시 계층 구조

L1 캐시

L1 캐시는 CPU 코어에 가장 가까운 캐시로, 명령어 캐시(L1I)와 데이터 캐시(L1D)로 분리(Harvard 구조)되어 있습니다. 접근 지연은 약 4~5 사이클이며, 코어당 독립적으로 존재합니다.

L2 캐시

L2 캐시는 명령어와 데이터를 통합(unified)하여 저장하며, 접근 지연은 약 12~14 사이클입니다. 대부분의 현대 프로세서에서 코어별 또는 코어 클러스터별로 할당됩니다.

L3 / LLC (Last-Level Cache)

L3 캐시는 패키지 내 여러 코어가 공유하는 LLC(Last-Level Cache)입니다. 접근 지연은 약 30~40 사이클이며, 용량은 수 MB에서 수백 MB(AMD 3D V-Cache)까지 다양합니다. Intel은 LLC를 코어별 슬라이스로 분산하고 링 버스/메시 인터커넥트로 연결하며, AMD는 CCX 단위로 L3를 공유합니다.

포함 / 배제 / NINE 정책

ARM 캐시 계층

ARM 프로세서는 제조사와 설계에 따라 캐시 구조가 다양하지만, 고성능 코어(Cortex-A/Neoverse)는 일반적으로 다음 계층을 따릅니다:

• DSU (DynamIQ Shared Unit): Cortex-A/X 혼합 클러스터의 L3 캐시와 인터커넥트. 최대 8개 코어가 공유.
• SLC (System Level Cache): ARM의 L3 명칭. 슬라이스 방식으로 분산 배치.
• CMN (Coherent Mesh Network): Neoverse 서버급 프로세서의 메시 인터커넥트. 여러 DSU를 연결.
• VIPT vs PIPT: L1D는 VIPT (Virtually-Indexed Physically-Tagged), L2/L3는 PIPT (Physically-Indexed Physically-Tagged)로 캐시 앨리어싱 회피.

캐시 연관도

직접 사상 (Direct-Mapped)

각 메모리 블록이 캐시의 정확히 한 위치에만 매핑됩니다. 구현이 간단하고 접근이 빠르지만 conflict miss가 빈번합니다. 현대 프로세서에서는 거의 사용되지 않습니다.

N-Way 집합 연관 (Set-Associative)

현대 캐시의 표준 방식입니다. 캐시를 여러 셋(set)으로 나누고, 각 셋에 N개의 웨이(way)를 둡니다. 메모리 주소는 하나의 셋에 매핑되지만, 그 셋 내 N개 웨이 중 아무 곳에나 저장될 수 있습니다.

셋 인덱스 계산:

셋 수 = 캐시 크기 / (캐시 라인 크기 × 연관도)
셋 인덱스 = (주소 / 캐시 라인 크기) % 셋 수

완전 연관 (Fully-Associative)

메모리 블록이 캐시의 어느 위치에나 저장될 수 있습니다. Conflict miss가 없지만 검색 비용이 높아 TLB 같은 소규모 캐시에 주로 사용됩니다.

태그 / 셋 / 오프셋 비트 분해

물리 주소는 세 영역으로 분해됩니다:

/* arch/x86/kernel/cpu/cacheinfo.c — ci_leaf_init() */
static void ci_leaf_init(struct cacheinfo *this_leaf,
                         struct _cpuid4_info_regs *base)
{
    this_leaf->level        = base->eax.split.level;
    this_leaf->type         = base->eax.split.type;
    this_leaf->coherency_line_size = base->ebx.split.coherency_line_size + 1;
    this_leaf->ways_of_associativity = base->ebx.split.ways_of_associativity + 1;
    this_leaf->size = this_leaf->number_of_sets *
                      this_leaf->coherency_line_size *
                      this_leaf->ways_of_associativity;
}

캐시 인덱싱 방식 (VIVT / VIPT / PIPT)

캐시 주소 변환 방식은 인덱스(Index)와 태그(Tag)를 가상/물리 주소 중 어떤 것으로 계산하는지에 따라 세 가지로 나뉩니다. 이 방식에 따라 TLB와의 파이프라인 관계, 컨텍스트 스위치 비용, 캐시 앨리어싱 문제가 달라집니다.

VIVT (Virtually-Indexed Virtually-Tagged)

인덱스와 태그 모두 가상 주소로 계산합니다. TLB를 기다리지 않아 가장 빠르지만, 두 가지 심각한 문제가 있습니다:

• 컨텍스트 스위치 시 전체 플러시: 다른 프로세스가 같은 가상 주소를 다른 물리 주소로 사용할 수 있어, 스위치마다 캐시를 완전히 비워야 합니다.
• Homonym 문제: 같은 가상 주소가 다른 물리 주소를 가리킬 때 캐시가 잘못된 데이터를 반환합니다.

초기 ARM 프로세서(ARM926 등)에서 사용됐으나 현대 설계에서는 거의 사용하지 않습니다.

VIPT (Virtually-Indexed Physically-Tagged)

인덱스는 가상 주소, 태그는 물리 주소로 계산합니다. TLB와 캐시 접근을 병렬로 시작하여 성능을 유지하면서 Homonym 문제를 해결합니다. x86 L1D와 ARM Cortex-A/X L1D가 이 방식을 사용합니다.

앨리어싱 회피 조건:

인덱스 비트 수 ≤ page_offset_bits (= log2(페이지 크기))

예: 페이지 크기 4KB (12비트), 캐시 라인 64B (6비트)
  셋 수 = 캐시 크기 / (라인 크기 × 웨이 수)
  인덱스 비트 = log2(셋 수) = log2(캐시 크기 / (64 × N))

  32KB 8-way: 셋 = 32768 / (64×8) = 64 → 인덱스 6비트 ≤ 12비트 → VIPT = PIPT (앨리어싱 없음)
  64KB 4-way: 셋 = 65536 / (64×4) = 256 → 인덱스 8비트 > 12비트 → 앨리어싱 가능!

인덱스 비트가 페이지 오프셋 비트보다 많으면 캐시 앨리어싱(aliasing)이 발생합니다. 같은 물리 페이지를 서로 다른 가상 주소로 매핑할 때, 인덱스가 달라져 캐시에 동일 데이터의 복사본이 두 곳에 생기는 문제입니다.

PIPT (Physically-Indexed Physically-Tagged)

인덱스와 태그 모두 물리 주소로 계산합니다. TLB 변환이 완료된 후 캐시를 접근하므로 앨리어싱 문제가 없습니다. ARM L2/L3(Cortex-A, Neoverse), x86 L2/L3가 사용합니다. 변환 대기 지연이 있지만, L2/L3는 L1보다 지연이 크므로 이 오버헤드가 상대적으로 작습니다.

커널에서의 앨리어싱 처리

VIPT 캐시에서 앨리어싱이 발생하는 ARM 아키텍처는 다음 함수로 관리합니다:

/* arch/arm/mm/cache-v7.c — VIPT 앨리어싱 캐시에서 페이지 플러시 */
void flush_cache_page(struct vm_area_struct *vma,
                      unsigned long user_addr, unsigned long pfn)
{
    unsigned long addr = pfn_to_kaddr(pfn);
    /* VIPT 앨리어싱: 사용자 VA + 커널 VA 양쪽 모두 플러시 */
    __flush_dcache_page(pfn, vma);
}

/* include/asm-generic/cacheflush.h */
void flush_dcache_page(struct page *page);
  /* DMA/mmap 후 물리 페이지 캐시 일관성 보장 — VIPT 아키텍처에서 필수 */

/* ARM64는 PIPT L1D를 사용하므로 flush_cache_page()가 NOP (no-op) */
/* ARM32 VIPT 캐시에서는 실제 캐시 라인 플러시 수행 */

캐시 교체 정책

LRU / Pseudo-LRU

캐시 셋이 가득 찼을 때 어떤 라인을 축출할지 결정하는 정책입니다.

• LRU (Least Recently Used): 가장 오래 사용되지 않은 라인을 축출. 이상적이지만 높은 연관도에서 상태 추적 비용이 큼.
• Pseudo-LRU (PLRU): 트리 기반의 근사 LRU. 8-way 셋에서 3비트 트리로 축출 후보를 O(1)에 결정. 현대 x86 프로세서에서 가장 널리 사용.

적응형 교체

• Intel Adaptive Replacement: Skylake 이후 LLC에서 접근 빈도와 최근성을 모두 고려하는 적응형 정책 사용.
• AMD: L3에서 워크로드에 따라 동적으로 교체 정책을 조정.
• ARM: 일부 구현에서 Random 교체를 사용하여 병적(pathological) 패턴 방지.

RRIP / SHIP — 현대 캐시 교체 알고리즘

Intel Haswell 이후의 LLC는 단순 LRU/PLRU 대신 더 정교한 교체 알고리즘을 사용합니다:

• RRIP (Re-Reference Interval Prediction): 각 캐시 라인에 2비트의 RRPV(Re-Reference Prediction Value)를 유지합니다. RRPV가 높을수록 곧 재접근될 가능성이 낮아 교체 우선 대상이 됩니다. 새 라인 삽입 시 RRPV=2(far)로 시작하여, 캐시 히트마다 RRPV를 0(near)으로 낮춥니다. LRU보다 스캔(scan) 워크로드에 더 강합니다.
• SHIP (Signature-based Hit Predictor): PC(Program Counter) 기반 접근 패턴을 시그니처 테이블(SHCT)에 기록하여 이전에 캐시 히트를 유발한 명령어인지 예측합니다. 히트 예측이 높으면 RRPV=0으로 삽입하여 캐시에 오래 유지합니다.

쓰기 정책

Write-Back

대부분의 현대 프로세서가 기본으로 사용하는 정책입니다. 쓰기 시 캐시만 갱신하고, 더티(dirty) 비트를 설정합니다. 캐시 라인이 축출될 때만 메모리에 기록하므로 메모리 대역폭을 절약합니다.

Write-Through

쓰기 시 캐시와 메모리를 동시에 갱신합니다. 코히런시 관리가 간단하지만 쓰기 대역폭을 많이 소모합니다. 일부 임베디드 시스템이나 특수 용도에서 사용됩니다.

Write-Allocate / No-Write-Allocate

• Write-Allocate (Fetch on Write): 쓰기 미스 시 캐시 라인을 먼저 로드한 후 쓰기. Write-Back과 조합이 일반적.
• No-Write-Allocate: 쓰기 미스 시 메모리에 직접 기록하고 캐시에 올리지 않음. Write-Through와 조합.

Write-Combining (WC)

WC는 캐시를 거치지 않고 쓰기 결합 버퍼(WC buffer)에 쓰기를 모아서 버스트 전송합니다. 프레임버퍼, MMIO 영역 등 순서가 중요하지 않은 비캐시 가능 영역에 적합합니다.

/* 프레임버퍼를 Write-Combining으로 설정 */
int set_memory_wc(unsigned long addr, int numpages);
int set_memory_wb(unsigned long addr, int numpages);

/* arch/x86/mm/pat/set_memory.c */
int set_memory_wc(unsigned long addr, int numpages)
{
    return change_page_attr_set(&addr, numpages,
                                cachemode2pgprot(_PAGE_CACHE_MODE_WC),
                                0);
}

캐시 코히런시 프로토콜

멀티코어 시스템에서 여러 코어의 캐시가 동일 메모리 주소의 다른 값을 가지면 안 됩니다. 캐시 코히런시 프로토콜은 각 캐시 라인의 상태를 추적하여 일관성을 보장합니다.

MESI 프로토콜

가장 기본적인 코히런시 프로토콜로, 각 캐시 라인은 네 가지 상태 중 하나입니다:

• Modified (M): 이 코어만 가지고 있으며, 메모리보다 새로운 값 (dirty).
• Exclusive (E): 이 코어만 가지고 있으며, 메모리와 같은 값 (clean).
• Shared (S): 여러 코어가 가지고 있으며, 메모리와 같은 값.
• Invalid (I): 유효하지 않은 라인 (빈 슬롯과 동일).

MOESI (AMD)

AMD는 MESI에 Owned (O) 상태를 추가한 MOESI 프로토콜을 사용합니다. Owned 상태의 코어는 다른 코어들과 데이터를 공유하면서도 수정된 값의 책임을 집니다 — 메모리에 쓰기를 지연시키면서 스누프 요청에 직접 응답할 수 있어, Modified→Shared 전환 시 불필요한 메모리 쓰기를 회피합니다.

MESIF (Intel)

Intel은 MESI에 Forward (F) 상태를 추가한 MESIF 프로토콜을 사용합니다. Shared 상태의 여러 코어 중 하나가 Forward로 지정되어 스누프 요청에 응답하는 역할을 합니다. 이를 통해 Shared 상태에서 여러 코어가 동시에 응답하는 중복을 방지합니다.

스누핑 vs 디렉토리 기반

ARM CHI (Coherent Hub Interface)

ARM의 고성능 프로세서(Neoverse, Cortex-A7x+)는 CHI (Coherent Hub Interface) 프로토콜을 사용합니다. CHI는 디렉토리 기반 코히런시로 수백 코어까지 확장 가능합니다.

CHI 구성 요소

• RN-F (Request Node - Fully coherent): CPU 클러스터. 코히런트 요청 발행.
• HN-F (Home Node - Fully coherent): 메모리 컨트롤러. 디렉토리 유지, 스누프 조정.
• SN-F (Slave Node - Fully coherent): L3/SLC 슬라이스. 캐시 데이터 저장.
• RN-I/RN-D: 비코히런트 I/O 디바이스.

CHI 캐시 상태 (MOESI 확장)

CHI는 MOESI를 확장한 7개 상태를 사용합니다:

CHI 장점

• 확장성: 디렉토리 기반으로 브로드캐스트 스누프 불필요. CMN 메시로 수백 코어 연결 가능.
• 대역폭 효율: 스누프 트래픽이 관련 노드에만 전송. 불필요한 브로드캐스트 제거.
• QoS 지원: 트랜잭션별 우선순위로 latency-critical 워크로드 보호.
• DVM (Distributed Virtual Memory): TLB/캐시 유지보수 작업을 분산 처리. TLBI 명령어가 CHI를 통해 전파.

TLB (Translation Lookaside Buffer)

TLB는 가상→물리 주소 변환 결과를 캐싱하는 특수 캐시로, 페이지 테이블 워크 비용(수십~수백 사이클)을 1~2 사이클로 줄입니다.

TLB 계층

Hugepage와 TLB Reach

TLB reach는 TLB가 커버할 수 있는 최대 가상 주소 범위입니다:

TLB reach = TLB 엔트리 수 × 페이지 크기
  4K × 2048 = 8MB       /* L2 STLB, 4K 페이지 */
  2M × 2048 = 4GB       /* L2 STLB, 2M hugepage */

Hugepage(2MB/1GB)를 사용하면 동일한 TLB 엔트리 수로 훨씬 넓은 범위를 커버하여 TLB 미스를 크게 줄일 수 있습니다. 커널의 THP(Transparent Huge Pages)는 이를 자동으로 활용합니다.

Hugepage 성능 효과

실제 측정 결과 (4GB 메모리 랜덤 접근 워크로드):

# Hugepage 효과 측정
# 1) 기본 4K 페이지
echo never > /sys/kernel/mm/transparent_hugepage/enabled
perf stat -e dTLB-load-misses,dTLB-loads ./memory_intensive

# 2) THP 활성화 (2MB)
echo always > /sys/kernel/mm/transparent_hugepage/enabled
perf stat -e dTLB-load-misses,dTLB-loads ./memory_intensive

# 3) 1GB hugepage 할당 (사전 예약 필요)
echo 4 > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages
numactl --membind=0 ./memory_intensive_1g

TLB Shootdown

페이지 테이블을 변경한 후 다른 코어의 TLB에 남아 있는 오래된 매핑을 무효화해야 합니다. 이를 TLB shootdown이라 하며, IPI(Inter-Processor Interrupt)를 사용합니다.

/* mm/tlb.c — TLB 일괄 플러시 */
void flush_tlb_mm_range(struct mm_struct *mm,
                        unsigned long start, unsigned long end,
                        unsigned int stride_shift, bool freed_tables)
{
    /* 로컬 CPU 플러시 */
    if (cpumask_any_but(mm_cpumask(mm), smp_processor_id()) < nr_cpu_ids)
        flush_tlb_others(mm_cpumask(mm), &info); /* IPI 전송 */
    else
        local_flush_tlb();
}

/* PCID (Process Context ID): TLB 태그로 프로세스 구분 → 컨텍스트 스위치 시 전체 플러시 불필요 */
/* ASID (ARM): 동일 목적, 8~16비트 태그 */

캐시 프리페칭

하드웨어 프리페처

현대 프로세서는 메모리 접근 패턴을 감지하여 자동으로 데이터를 미리 캐시에 로드합니다:

• Stride prefetcher: 일정한 간격(stride)의 접근 패턴을 감지. 배열 순회에 효과적.
• Stream prefetcher: 연속 주소 접근을 감지하여 다음 캐시 라인을 미리 로드.
• Spatial prefetcher: 캐시 라인 쌍(pair)을 함께 로드. Intel L2 Adjacent Cache Line Prefetcher.
• Intel L2 Streamer: L2 미스를 모니터링하여 최대 20 캐시 라인 앞까지 프리페치.

소프트웨어 프리페치

커널은 명시적 프리페치 명령으로 하드웨어 프리페처를 보완합니다:

/* include/linux/prefetch.h */
#define prefetch(x) __builtin_prefetch(x, 0, 3)  /* 읽기, 높은 시간적 지역성 */
#define prefetchw(x) __builtin_prefetch(x, 1, 3) /* 쓰기, 높은 시간적 지역성 */

/*
 * __builtin_prefetch(addr, rw, locality)
 *   rw:       0 = 읽기, 1 = 쓰기
 *   locality: 0 = NTA(비시간적), 1 = T2, 2 = T1, 3 = T0(가장 가까운 캐시)
 */

커널 사용 사례

네트워크 스택에서 sk_buff의 다음 패킷을 미리 프리페치하여 캐시 미스를 줄이는 패턴:

/* net/core/dev.c — NAPI 폴링에서 프리페치 */
static void skb_defer_free_flush(struct softnet_data *sd)
{
    struct sk_buff *skb, *next;
    llist_for_each_entry_safe(skb, next, ...) {
        prefetch(next);          /* 다음 skb를 미리 캐시에 로드 */
        __kfree_skb(skb);
    }
}

AMD Zen4 프리페처와 CLDEMOTE

AMD Zen4 이후의 프리페처와 Intel Tiger Lake 이후의 새 캐시 명령어입니다:

• AMD MFMA 프리페처 (Zen4): AI/머신러닝 워크로드의 행렬 접근 패턴(_mm512_loadu_ps 등)을 감지하여 MFMA 명령어 실행 전 데이터를 미리 L2로 로드합니다. 대규모 행렬 곱(GEMM)에서 LLC 미스를 크게 줄입니다.
• PREFETCHRST2: AMD Zen4의 확장 프리페치 명령어. PREFETCHT2와 유사하지만 실패 시 재시작(restart) 시 성능 패널티를 줄이도록 최적화되었습니다.

/* CLDEMOTE: 데이터를 하위 캐시 레벨로 내리기 (Intel Tiger Lake+, 2020) */
/* 반대: PREFETCHT0이 데이터를 L1으로 올림, CLDEMOTE는 L1→L2/L3로 내림 */
static inline void cldemote(const void *addr)
{
    asm volatile(".byte 0x0f, 0x1c, 0x07"  /* CLDEMOTE [rdi] */
                 :               : "D" (addr)
                 : "memory");
}

/* 사용 예: 생산자-소비자 패턴에서 생산 완료 후 데이터를 L2로 내려
 * 다른 코어가 L2에서 읽도록 유도. MESI Exclusive → LLC 수준으로 이동 */
void producer_finish(void *item)
{
    /* 데이터 처리 완료 */
    process_item(item);
    /* 소비자 코어가 LLC에서 가져가도록 힌트 */
    cldemote(item);
    /* 소비자에게 알림 */
    enqueue(item);
}

캐시 파티셔닝 — Intel RDT

Intel RDT(Resource Director Technology)는 LLC와 메모리 대역폭을 태스크/컨테이너 단위로 파티셔닝하는 하드웨어 기능입니다.

CAT (Cache Allocation Technology)

CAT는 LLC(L3) 또는 L2를 CBM(Capacity Bitmask)으로 파티셔닝합니다. 각 비트가 캐시 웨이 그룹을 나타내며, CLOSID(Class of Service ID)별로 다른 CBM을 할당합니다.

# resctrl 마운트
mount -t resctrl resctrl /sys/fs/resctrl

# CBM 구조 확인 (11비트 = 11개 웨이 그룹)
cat /sys/fs/resctrl/info/L3/cbm_mask
# 7ff (0b11111111111)

# 실시간 태스크용 파티션 생성 (상위 4개 웨이 독점)
mkdir /sys/fs/resctrl/rt_group
echo "L3:0=f00" > /sys/fs/resctrl/rt_group/schemata
echo $RT_PID > /sys/fs/resctrl/rt_group/tasks

CDP (Code and Data Prioritization)

CDP는 CAT를 확장하여 코드(명령어)와 데이터에 별도의 CBM을 할당합니다. 코드가 큰 워크로드(JIT 컴파일러 등)에서 데이터 캐시 오염을 방지할 수 있습니다.

# CDP 활성화
mount -t resctrl resctrl /sys/fs/resctrl -o cdp

# 코드에 웨이 0-3, 데이터에 웨이 4-7 할당
echo "L3:0=00f;0=0f0" > /sys/fs/resctrl/jit_group/schemata

MBA (Memory Bandwidth Allocation)

MBA는 메모리 대역폭을 백분율로 제한합니다. noisy neighbor 문제를 완화하여 지연 민감 워크로드를 보호합니다.

resctrl 파일시스템

NUMA와 캐시 Affinity

NUMA(Non-Uniform Memory Access) 시스템에서 LLC는 각 소켓(노드)의 코어들과 연결됩니다. 로컬 NUMA 노드의 LLC를 통한 메모리 접근은 빠르지만, 원격 NUMA 노드의 LLC를 경유하거나 원격 DRAM에 접근하면 지연이 크게 증가합니다.

NUMA 접근 지연 비교

NUMA 메모리 정책과 캐시

커널의 NUMA 정책은 메모리 할당 위치를 결정하며, 이는 캐시 지역성에 직접 영향을 줍니다:

/* include/linux/mempolicy.h — NUMA 메모리 정책 */
#define MPOL_DEFAULT    0  /* 로컬 노드 우선 */
#define MPOL_BIND       2  /* 지정 노드에만 할당 */
#define MPOL_INTERLEAVE 3  /* 노드 간 라운드로빈 */
#define MPOL_PREFERRED  1  /* 선호 노드, 없으면 다른 노드 허용 */
#define MPOL_LOCAL      4  /* 항상 로컬 노드 (strict) */

/* 시스템 콜: 정책 설정 */
int set_mempolicy(int mode, const unsigned long *nmask,
                  unsigned long maxnode);

/* 범위별 정책 (mmap 영역에 적용) */
int mbind(void *addr, unsigned long len, int mode,
          const unsigned long *nmask, unsigned long maxnode,
          unsigned flags);

NUMA 캐시 핫스팟 탐지

# 1) NUMA 통계 개요
numastat -c

# 2) LLC 미스율에서 NUMA 영향 확인
perf stat -e LLC-load-misses,LLC-loads,node-load-misses,node-loads \
  -p $(pgrep myapp) -- sleep 10

# 3) 특정 노드에 프로세스 바인딩
numactl --cpunodebind=0 --membind=0 ./myapp

# 4) NUMA 원격 접근 비율 실시간 모니터링
watch -n 1 'cat /sys/devices/system/node/node*/numastat'

# 5) perf mem으로 원격 NUMA 접근 분석 (PEBS 필요)
perf mem record -a -- sleep 5
perf mem report --sort=mem | head -30
# "Remote LLC" / "Remote DRAM" 항목이 많으면 NUMA 병목

# bpftrace: NUMA 노드별 캐시 미스 집계
bpftrace -e 'hardware:cache-misses:1000 {
    @node[cpu / 4] = count();   /* cpu를 노드로 매핑 (4코어/노드 가정) */
    @comm[comm] = count();
}
END {
    print(@node); print(@comm);
}'

False Sharing

발생 메커니즘

두 코어가 같은 캐시 라인에 있는 서로 다른 변수를 독립적으로 수정하면, 코히런시 프로토콜이 캐시 라인 전체를 반복적으로 무효화합니다. 논리적으로 공유가 없지만 물리적으로 캐시 라인을 공유하여 성능이 극심하게 저하됩니다.

/* 문제: counter_a와 counter_b가 같은 캐시 라인에 위치 */
struct shared_counters {
    atomic_t counter_a;  /* CPU 0이 수정 */
    atomic_t counter_b;  /* CPU 1이 수정 → false sharing! */
};

/* 수정: 패딩으로 각 카운터를 별도 캐시 라인에 배치 */
struct shared_counters_fixed {
    atomic_t counter_a;
    char     __pad[L1_CACHE_BYTES - sizeof(atomic_t)];
    atomic_t counter_b;
} ____cacheline_aligned;

탐지

perf c2c는 false sharing을 탐지하는 가장 강력한 도구입니다:

# false sharing 프로파일링
perf c2c record -a -- sleep 10
perf c2c report --stdio

# 출력에서 HITM(Hit in Modified) 비율이 높은 캐시 라인 확인
# Shared Data Cache Line Table에서 문제 변수와 소스 위치 표시

완화

• __cacheline_aligned_in_smp: SMP 빌드에서만 캐시 라인 정렬 (UP에서는 낭비 방지).
• per-CPU 변수: DEFINE_PER_CPU()로 코어마다 독립 복사본을 유지하면 공유 자체가 없음.
• pahole: 구조체의 캐시 라인 레이아웃을 시각화하여 false sharing 후보를 탐지.

# pahole로 구조체 레이아웃 확인
pahole --class_name task_struct vmlinux | head -50

# 각 필드의 오프셋과 캐시 라인 경계를 표시

성능 영향 측정

실제 벤치마크 결과로 false sharing의 성능 저하를 확인할 수 있습니다:

테스트 환경: Intel Xeon Gold 6248R (24코어), 2개 스레드가 각각 atomic_inc() 1억 회 실행

/* 벤치마크 재현 코드 */
#include <pthread.h>
#include <stdatomic.h>
#include <stdio.h>

/* Case 1: False Sharing (같은 캐시 라인) */
struct shared_line {
    atomic_int counter_a;
    atomic_int counter_b;  /* 64바이트 미만 간격 → false sharing */
} shared;

/* Case 2: 패딩 적용 (별도 캐시 라인) */
struct padded_line {
    atomic_int counter_a;
    char __pad[64 - sizeof(atomic_int)];
    atomic_int counter_b;
} padded;

void *worker_a(void *arg) {
    for (int i = 0; i < 100000000; i++)
        atomic_fetch_add(&shared.counter_a, 1);
    return NULL;
}

void *worker_b(void *arg) {
    for (int i = 0; i < 100000000; i++)
        atomic_fetch_add(&shared.counter_b, 1);
    return NULL;
}

/* 컴파일: gcc -O2 -pthread false_sharing.c -o false_sharing
 * 측정: perf stat -e cache-references,cache-misses,L1-dcache-load-misses ./false_sharing
 * 진단: perf c2c record ./false_sharing && perf c2c report */

캐시 관리 명령어

CLFLUSH / CLFLUSHOPT

CLFLUSH는 지정된 주소의 캐시 라인을 모든 캐시 계층에서 무효화하고, 더티 라인이면 메모리에 기록합니다. CLFLUSHOPT는 CLFLUSH의 최적화 버전으로 순서 제약이 느슨하여 병렬 플러시가 가능합니다.

CLWB (Cache Line Write Back)

CLWB는 더티 캐시 라인을 메모리에 기록하되, 캐시에서 무효화하지 않습니다. Persistent Memory(PMEM)에서 데이터를 영속 매체에 기록하면서도 캐시 성능을 유지하는 데 핵심적입니다.

WBINVD / INVD

• WBINVD: CPU의 전체 캐시를 메모리에 기록 후 무효화. 매우 느리고 모든 코어에 영향. 리셋, 절전 진입 시 사용.
• INVD: 전체 캐시를 기록 없이 무효화. 데이터 손실 위험. BIOS/펌웨어 전용.

Non-Temporal 스토어

Non-Temporal 스토어(MOVNTI, MOVNTPS 등)는 캐시를 우회하여 메모리에 직접 기록합니다. 대량 데이터 복사 시 캐시 오염을 방지합니다.

/* arch/x86/include/asm/special_insns.h */
static inline void clflush(volatile void *__p)
{
    asm volatile("clflush %0" : "+m" (*(volatile char *)__p));
}

static inline void clflushopt(volatile void *__p)
{
    alternative_io(".byte 0x3e; clflush %0",
                   ".byte 0x66; clflush %0",
                   X86_FEATURE_CLFLUSHOPT,
                   "+m" (*(volatile char *)__p));
}

static inline void clwb(volatile void *__p)
{
    volatile struct { char x[64]; } *__v = __p;
    asm volatile(".byte 0x66, 0x0f, 0xae, 0x30"
                 : "+m" (*__v));
}

Persistent Memory (PMEM)와 캐시 관리

Intel Optane DIMM, CXL Type3 메모리 등의 Persistent Memory(PMEM)는 전원이 꺼져도 데이터가 유지되는 바이트 주소 지정 가능 저장 장치입니다. PMEM을 올바르게 사용하려면 CPU 캐시의 영속성(persistence)을 명시적으로 관리해야 합니다.

ADR과 eADR: 전원 장애 안전 도메인

PMEM에서 데이터 영속성은 안전 도메인(persistence domain) 개념으로 정의됩니다:

ADR: 전원 장애 시 메모리 컨트롤러의 쓰기 큐까지만 데이터가 안전합니다. CPU 캐시의 더티 라인은 손실됩니다. 따라서 데이터를 영속화하려면 반드시 CLWB → SFENCE 시퀀스로 캐시를 메모리 컨트롤러까지 내려보내야 합니다.

eADR: CPU 캐시 전체가 배터리 백업 도메인에 포함됩니다. CLWB 없이도 캐시에 기록된 데이터가 안전하지만, 순서 보장을 위해 SFENCE는 여전히 필요합니다. Intel Sapphire Rapids, Granite Rapids 일부 구성에서 지원합니다.

CLWB → SFENCE 영속화 패턴

/* 1) 기본 영속화 패턴 (ADR 환경) */
void pmem_persist(const void *addr, size_t len)
{
    const char *ptr = (const char *)addr;
    const char *end = ptr + len;

    /* 각 캐시 라인을 메모리 컨트롤러까지 write-back (캐시 유지) */
    for (; ptr < end; ptr += 64)
        clwb(ptr);  /* CLWB: 캐시 라인 기록, 무효화하지 않음 */

    /* 스토어 순서를 보장 — CLWB 이전 쓰기가 완전히 메모리에 도달 */
    asm volatile("sfence" ::: "memory");
}

/* 2) 커널 PMEM API (drivers/nvdimm/pmem.c) */
static void pmem_submit_bio(struct bio *bio)
{
    /* DAX 쓰기: memcpy 후 arch_wb_cache_pmem() 호출 */
    __copy_from_iter(pmem_addr, &iter, len);
    arch_wb_cache_pmem(pmem_addr, len);  /* = CLWB 루프 + SFENCE */
    nvdimm_flush(nd_region, bio);
}

/* 3) libpmem 사용 (userspace PMEM 라이브러리) */
/* pmem_persist(addr, len)  → CLWB + SFENCE */
/* pmem_msync(addr, len)    → msync() (ADR 보장이 없는 경우 fallback) */
/* pmem_is_pmem(addr, len)  → /proc/iomem에서 PMEM 여부 확인 */

커널 DAX (Direct Access) 코드 경로

DAX는 파일시스템을 통해 PMEM에 직접(Page Cache 없이) 접근하는 메커니즘입니다. Page Cache를 우회하여 PMEM 주소에 직접 mmap/read/write를 수행합니다:

/* fs/dax.c — DAX 직접 접근 */
long dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff,
                        long nr_pages, enum dax_access_mode mode,
                        void **kaddr, pfn_t *pfn)
{
    /* PMEM 물리 주소를 커널 가상 주소로 매핑 */
    return dax_dev->ops->direct_access(dax_dev, pgoff, nr_pages,
                                          mode, kaddr, pfn);
}

/* arch/x86/mm/pat/set_memory.c — DAX 영역은 Write-Back 캐시 가능 */
/* 단, 영속화를 위해 clwb + sfence가 쓰기 경로에 반드시 포함되어야 함 */
void dax_flush(struct dax_device *dax_dev, void *addr, size_t size)
{
    if (unlikely(!dax_write_cache_enabled(dax_dev)))
        arch_wb_cache_pmem(addr, size);
}

커널 캐시 API

캐시 플러시 API

아키텍처 독립적인 캐시 관리 API:

/* include/asm-generic/cacheflush.h */
void flush_cache_all(void);                  /* 전체 캐시 플러시 */
void flush_cache_range(struct vm_area_struct *vma,
                       unsigned long start, unsigned long end);
void flush_cache_page(struct vm_area_struct *vma,
                      unsigned long addr, unsigned long pfn);
void flush_icache_range(unsigned long start, unsigned long end);

메모리 타입 변경 (PAT)

/* arch/x86/mm/pat/set_memory.c */
int set_memory_uc(unsigned long addr, int numpages);  /* Uncacheable */
int set_memory_wc(unsigned long addr, int numpages);  /* Write-Combining */
int set_memory_wb(unsigned long addr, int numpages);  /* Write-Back (기본) */
int set_memory_wt(unsigned long addr, int numpages);  /* Write-Through */

kmap과 캐시 일관성

VIPT(Virtually-Indexed Physically-Tagged) 캐시를 사용하는 아키텍처(일부 ARM)에서는 같은 물리 페이지가 다른 가상 주소로 매핑될 때 캐시 앨리어싱(aliasing) 문제가 발생할 수 있습니다. kmap()/kunmap()은 이를 고려하여 일관된 매핑을 제공합니다.

DMA 캐시 동기화

DMA 전송 전후에 CPU 캐시와 디바이스 간 일관성을 보장해야 합니다:

/* DMA 방향별 캐시 동기화 */
dma_sync_single_for_cpu(dev, dma_handle, size, DMA_FROM_DEVICE);
  /* 디바이스→CPU 전송 후: 캐시를 무효화하여 새 데이터 읽기 */

dma_sync_single_for_device(dev, dma_handle, size, DMA_TO_DEVICE);
  /* CPU→디바이스 전송 전: 캐시를 플러시하여 메모리에 기록 */

실전 진단

perf stat 캐시 이벤트

# L1/LLC 캐시 미스율 측정
perf stat -e cache-references,cache-misses,\
L1-dcache-loads,L1-dcache-load-misses,\
LLC-loads,LLC-load-misses,\
dTLB-loads,dTLB-load-misses \
-- ./workload

# 출력 예시:
#  1,234,567  cache-references
#    123,456  cache-misses        # 10.00% of all cache refs
#  5,678,901  L1-dcache-loads
#    567,890  L1-dcache-load-misses  # 10.00%
#    234,567  LLC-loads
#     23,456  LLC-load-misses     # 10.00%
#  4,567,890  dTLB-loads
#      4,567  dTLB-load-misses    #  0.10%

perf c2c

Cache-to-Cache 전송과 false sharing을 분석하는 전문 도구:

# 시스템 전체 C2C 프로파일링 (10초)
perf c2c record -a -- sleep 10

# 보고서 생성
perf c2c report --stdio

# 주요 확인 항목:
# 1) Shared Data Cache Line Table → HITM 비율이 높은 캐시 라인
# 2) 해당 캐시 라인을 접근하는 소스 코드 위치
# 3) Load/Store 비율과 접근 CPU 분포

eBPF 기반 캐시 분석

eBPF 도구를 사용하면 커널 수준에서 프로세스/코어별 캐시 미스를 실시간으로 분석할 수 있습니다:

bpftrace — 프로세스별 캐시 미스

# 프로세스별 LLC 미스 카운트 (1000개 미스마다 샘플링)
bpftrace -e 'hardware:cache-misses:1000 {
    @misses[comm, pid] = count();
}
END {
    print(@misses);
}'

# L1 dcache 미스 상위 10개 프로세스
bpftrace -e '
hardware:L1-dcache-load-misses:500 {
    @[comm] = count();
}
END {
    print(@, 10);
}'

# 스택 트레이스 포함 LLC 미스 (핫스팟 함수 식별)
bpftrace -e '
hardware:cache-misses:10000 {
    @[ustack()] = count();
}
END {
    print(@, 5);
}'

llcstat (BCC) — 코어/프로세스별 LLC 히트율

# LLC 히트율 통계 (1초 간격, 10회)
llcstat-bpfcc 1 10

# 출력 예시:
# PID    NAME         CPU    REFERENCE   MISS    HIT%
# 1234   mysqld       0      542,312     48,721  91.02%
# 5678   python3      2      123,456     98,765  20.00%
# ← python3의 낮은 히트율: 무작위 메모리 접근 패턴 의심

# 특정 프로세스만 모니터링
llcstat-bpfcc -p $(pgrep myapp)

perf mem — 메모리 접근 지연 분석

# 메모리 접근 지연 기록 (PEBS 또는 ARM SPE 필요)
perf mem record -a -- sleep 5

# 접근 지연 분포 보고서
perf mem report --sort=mem,sym | head -40

# 주요 출력 컬럼:
# Overhead — 지연 샘플 비율
# Memory access — 데이터 출처 (L1/L2/L3/Remote/DRAM)
# Symbol — 접근한 함수
#
# 출력 예시:
#  45.23%  L1 hit         spin_lock
#  28.11%  L2 hit         __kmalloc
#  12.34%  LLC hit        copy_page
#   8.45%  Remote LLC     shared_data_update  ← NUMA 문제!
#   5.87%  Local DRAM     page_fault_handler

# Intel VTune CLI (설치 시)
# vtune -collect memory-access -knob analyze-mem-objects=true -- ./myapp
# vtune -report summary -result vtune_results/

Valgrind Cachegrind

# 캐시 시뮬레이션 기반 프로파일링 (유저 공간 프로그램)
valgrind --tool=cachegrind ./program
cg_annotate cachegrind.out.<pid>

# 함수별/라인별 캐시 미스 수를 상세히 보여줌
# I1/D1/LL(Last-Level) 미스를 각각 표시

sysfs 캐시 인터페이스

# CPU0의 캐시 정보 확인
for i in /sys/devices/system/cpu/cpu0/cache/index*/; do
  echo "=== $(cat $i/level) $(cat $i/type) ==="
  echo "  size:         $(cat $i/size)"
  echo "  ways:         $(cat $i/ways_of_associativity)"
  echo "  sets:         $(cat $i/number_of_sets)"
  echo "  line_size:    $(cat $i/coherency_line_size)"
  echo "  shared_cpus:  $(cat $i/shared_cpu_list)"
done

# 출력 예시:
# === 1 Data ===
#   size:         48K
#   ways:         12
#   sets:         64
#   line_size:    64
#   shared_cpus:  0,8
# === 1 Instruction ===
#   size:         32K
# === 2 Unified ===
#   size:         1280K
# === 3 Unified ===
#   size:         18432K
#   shared_cpus:  0-7

캐시 미스 실습 예제

다음 예제는 캐시 동작 원리를 직접 관찰하고 측정하는 실습 코드입니다.

공간적 지역성 실험

/* cache_locality.c — 행 우선 vs 열 우선 접근 비교 */
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define SIZE 4096

int main() {
    int (*matrix)[SIZE] = malloc(sizeof(int) * SIZE * SIZE);
    long sum = 0;
    struct timespec start, end;

    /* Case 1: 행 우선 (Row-major) — 캐시 친화적 */
    clock_gettime(CLOCK_MONOTONIC, &start);
    for (int i = 0; i < SIZE; i++)
        for (int j = 0; j < SIZE; j++)
            sum += matrix[i][j];
    clock_gettime(CLOCK_MONOTONIC, &end);
    long row_ns = (end.tv_sec - start.tv_sec) * 1000000000L +
                  (end.tv_nsec - start.tv_nsec);
    printf("Row-major: %ld ns\n", row_ns);

    /* Case 2: 열 우선 (Column-major) — 캐시 미스 유발 */
    sum = 0;
    clock_gettime(CLOCK_MONOTONIC, &start);
    for (int j = 0; j < SIZE; j++)
        for (int i = 0; i < SIZE; i++)
            sum += matrix[i][j];  /* stride = SIZE × 4바이트 */
    clock_gettime(CLOCK_MONOTONIC, &end);
    long col_ns = (end.tv_sec - start.tv_sec) * 1000000000L +
                  (end.tv_nsec - start.tv_nsec);
    printf("Column-major: %ld ns (%.1fx slower)\n",
           col_ns, (double)col_ns / row_ns);

    free(matrix);
    return 0;
}

/* 측정 예시 결과:
 * Row-major:    180,000,000 ns (180ms)
 * Column-major: 920,000,000 ns (920ms) — 5.1x slower
 *
 * perf로 확인:
 * $ perf stat -e cache-references,cache-misses,L1-dcache-load-misses \
 *     ./cache_locality
 *
 * Row-major:    L1 미스율 ~8%  (공간 지역성 활용)
 * Column-major: L1 미스율 ~95% (stride가 캐시 라인 크기 초과)
 */

캐시 스래싱 실험

/* cache_thrashing.c — 캐시 셋 충돌 재현 */
#include <stdio.h>
#include <stdlib.h>

#define CACHE_SIZE   (256 * 1024)    /* 256KB L2 캐시 */
#define LINE_SIZE    64
#define ASSOCIATIVITY 8            /* 8-way set associative */
#define NUM_SETS     (CACHE_SIZE / (LINE_SIZE * ASSOCIATIVITY))
#define SET_STRIDE   (NUM_SETS * LINE_SIZE)  /* 같은 셋에 매핑되는 주소 간격 */

int main() {
    char *buf = aligned_alloc(LINE_SIZE, SET_STRIDE * 16);
    volatile char temp;

    /* Case 1: 캐시에 수용 가능 (8개 라인 → 1개 셋의 8-way에 정확히 맞음) */
    for (int iter = 0; iter < 1000000; iter++)
        for (int i = 0; i < 8; i++)
            temp = buf[i * SET_STRIDE];
    printf("8 lines: cache hit (fits in 8-way set)\n");

    /* Case 2: 캐시 스래싱 (9개 라인 → 계속 축출 발생) */
    for (int iter = 0; iter < 1000000; iter++)
        for (int i = 0; i < 9; i++)
            temp = buf[i * SET_STRIDE];  /* 9번째가 1번째를 축출 */
    printf("9 lines: cache thrashing (conflict miss)\n");

    free(buf);
    return 0;
}

/* perf 측정:
 * $ perf stat -e L1-dcache-loads,L1-dcache-load-misses,\
 *   LLC-loads,LLC-load-misses ./cache_thrashing
 *
 * 8 lines:  L1 미스율 ~1%  (모두 캐시에 상주)
 * 9 lines:  L1 미스율 ~99% (매 접근마다 conflict miss)
 */

프리페치 거리 실험

/* prefetch_distance.c — 소프트웨어 프리페치 효과 */
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#define SIZE (16 * 1024 * 1024)  /* 16M 요소 */
#define STRIDE 16                /* 16개씩 건너뛰며 접근 */

int main() {
    int *arr = malloc(SIZE * sizeof(int));
    long sum = 0;

    /* Case 1: 프리페치 없음 */
    for (int i = 0; i < SIZE; i += STRIDE)
        sum += arr[i];

    /* Case 2: 프리페치 적용 (8 라인 앞을 미리 로드) */
    sum = 0;
    for (int i = 0; i < SIZE; i += STRIDE) {
        __builtin_prefetch(&arr[i + STRIDE * 8], 0, 0);  /* NTA 힌트 */
        sum += arr[i];
    }

    free(arr);
    return 0;
}

/* 프리페치 거리 최적화:
 * - 너무 짧으면: 메모리 지연을 숨기지 못함
 * - 너무 길면: 프리페치된 데이터가 사용 전에 축출됨
 * - 최적값: 메모리 지연(~200 사이클) / 루프 처리량(사이클/iter)
 *
 * 예: 루프가 iter당 10사이클이면 → 200/10 = 20 iter 앞을 프리페치
 */

관련 문서

CPU 캐시와 관련된 다른 주제를 더 깊이 이해하고 싶다면 다음 문서를 참고하세요.

• 프로세스 스케줄러 — 캐시 친화적 스케줄링
• CPU 토폴로지 — 캐시 계층
• 메모리 배리어 — 캐시 일관성
• 최적화 — 캐시 최적화