Embedded Performance Engineering · 31/57

False Sharing 진단 — Cache Line Ping-Pong·Padding·측정

2026년 4월 26일 · Hawk · 4분 읽기

false-sharing cacheline padding coherence

#한 줄 요약

“False Sharing = 다른 변수, 같은 cache line” 입니다. 코어 간 ping-pong이 일어나 10~100배까지 느려집니다.

#메커니즘

1
struct {
2
    int counter_a;   // CPU 0 사용
3
    int counter_b;   // CPU 1 사용
4
} stats;   // 8 byte — 같은 64-byte line
5

6
CPU 0: writes counter_a
7
  → cache line state = Modified (CPU 0)
8
  → CPU 1 line state = Invalid
9

10
CPU 1: writes counter_b
11
  → coherence protocol triggered
12
  → CPU 0 line evict (flush to L2)
13
  → CPU 1 fetch from L2 (or CPU 0 cache)
14
  → CPU 1 cache state = Modified
15
  → CPU 0 = Invalid

매 access마다 line이 두 cache 사이를 왕복합니다(ping-pong). 실제로 공유되는 데이터는 하나도 없는데, 단지 같은 line에 들어 있다는 이유로 coherence가 계속 동작합니다.

그림으로 보면 두 코어가 같은 line을 두고 핑퐁하는 모습이 분명해집니다.

두 코어가 같은 cache line의 다른 변수에 접근할 때의 invalidate ping-pong

#MESI Protocol

1
M (Modified)  — 이 cache만 valid, dirty
2
E (Exclusive) — 이 cache만 valid, clean
3
S (Shared)    — 여러 cache valid, clean
4
I (Invalid)   — 무효

State 변화는 다음과 같이 일어납니다.

1
CPU 0 write: I → M, 다른 cache invalidate broadcast
2
CPU 1 read after CPU 0 write:
3
  - CPU 0 cache의 M line → flush to memory
4
  - CPU 0: M → S, CPU 1: I → S
5

6
False sharing = 매번 M → I → M → I 반복.

#측정 — 실 cycle

1
struct {
2
    atomic_int a;
3
    atomic_int b;
4
} bad;
5

6
struct {
7
    alignas(64) atomic_int a;
8
    alignas(64) atomic_int b;
9
} good;
10

11
void thread1_func(void *p) {
12
    for (int i = 0; i < 10M; i++) atomic_fetch_add(&bad.a, 1);
13
}
14
void thread2_func(void *p) {
15
    for (int i = 0; i < 10M; i++) atomic_fetch_add(&bad.b, 1);
16
}

Cortex-A72 4-core 환경에서 실측한 결과는 다음과 같습니다.

1
Bad (false sharing):  4.2 sec
2
Good (padded):        0.3 sec
3
                      → 14x slowdown

#Padding

1
struct counters {
2
    alignas(64) atomic_int a;
3
    char pad_a[64 - sizeof(atomic_int)];
4

5
    alignas(64) atomic_int b;
6
    char pad_b[64 - sizeof(atomic_int)];
7
};

또는 C++17:

1
#include <new>
2
struct alignas(std::hardware_destructive_interference_size) Counter {
3
    std::atomic<int> value;
4
};
5

6
std::array<Counter, 4> counters;   // 각 element가 다른 line

hardware_destructive_interference_size는 일반적으로 64이고, Apple M1은 128입니다.

#1. Per-CPU 변수

1
int counters[NUM_CPUS];   // ← 8개 × 4 byte = 32 byte → 한 line 안
2
each cpu: counters[cpu]++
3
→ false sharing

padding을 넣거나 per-CPU memory로 분리해야 합니다.

1
struct counter_per_cpu {
2
    alignas(64) int value;
3
};
4
struct counter_per_cpu counters[NUM_CPUS];

#2. Producer/Consumer Queue

1
struct queue {
2
    size_t head;   // producer writes
3
    size_t tail;   // consumer writes
4
    /* ... data ... */
5
};

producer와 consumer가 다른 코어에서 동작하면 head와 tail이 같은 line에 들어가서 ping-pong이 발생합니다.

1
struct queue {
2
    alignas(64) atomic_size_t head;
3
    char pad[64 - sizeof(atomic_size_t)];
4
    alignas(64) atomic_size_t tail;
5
    char pad2[64 - sizeof(atomic_size_t)];
6
    /* ... data ... */
7
};

#3. Spinlock 인접 데이터

1
struct {
2
    spinlock_t lock;
3
    int data1;   // ← lock 잡힌 코어와 다른 코어가 동시 access 시 ping-pong
4
    int data2;
5
} resource;

lock과 data를 서로 다른 line에 분리해야 합니다.

#perf c2c — Cache-to-Cache 진단

1
sudo perf c2c record ./prog
2
sudo perf c2c report
3

4
# Output:
5
# - HITM events (Hit in Modified state — false sharing 시그너처)
6
# - Per-cache-line contention
7
# - Source code location

Linux kernel 4.10 이상에서 사용할 수 있으며, false sharing을 탐지하는 가장 강력한 도구입니다.

#Intel VTune Memory Access

VTune의 Memory Access analysis는 다음과 같은 정보를 제공합니다.

Per cache line latency
Local vs Remote DRAM access
Contended cache lines 보고

#Embedded — Cortex-A SMP

1
/* Linux on Cortex-A — 4 코어 */
2
DEFINE_PER_CPU(int, my_counter);   // 자동 padded
3

4
/* RTOS SMP — FreeRTOS 11 SMP 또는 Zephyr */
5
static atomic_t counters[NUM_CORES] __attribute__((aligned(64)));

Zephyr는 Z_KERNEL_STACK_DEFINE 등을 통해 자동으로 정렬을 맞춰 줍니다.

#False Sharing은 항상 나쁜가?

반드시 그렇지는 않습니다. Workload에 따라 다음과 같이 갈립니다.

Read 위주 → 모든 cache S state, ping-pong 없음, OK
Per-CPU 누적 → padding 필요
가끔 write → 측정해서 결정

모든 변수에 padding을 넣으면 line 하나당 실제 정보가 1 byte 수준으로 줄어 cache 효율이 떨어집니다.

1
atomic_int global_counter;
2
/* 모든 thread가 update */

이런 경우는 진짜 공유이지 false sharing이 아닙니다. 해결책으로는 다음 두 가지가 있습니다.

Per-CPU에서 누적한 뒤 주기적으로 합산
Sharded counter

1
atomic_int counter[NUM_CPUS];
2

3
int total(void) {
4
    int sum = 0;
5
    for (i = 0) sum += counter[i];
6
    return sum;
7
}

Read는 가끔이고 write가 자주 일어나는 경우라면 per-CPU shard를 쓰는 편이 좋습니다.

#Lock-free Queue 디자인

1
struct lockfree_spsc {
2
    alignas(64) atomic_size_t head;   // producer-only
3
    alignas(64) atomic_size_t tail;   // consumer-only
4
    alignas(64) T buf[CAPACITY];      // 별도 line
5
};

각 hot field가 서로 다른 line에 놓이도록 해서 false sharing을 0으로 만듭니다.

#자주 하는 실수

⚠️ 작은 변수만 padding

1
alignas(64) int a;
2
int b;                 // ← a 같은 line에 들어감

a 뒤 64 byte 영역은 다른 변수가 차지할 수 있습니다. 모든 변수에 alignas를 붙이거나 명시적으로 pad를 넣어야 합니다.

⚠️ Padding 안에 다른 data

1
struct foo {
2
    alignas(64) int a;
3
    char tmp[60];
4
    alignas(64) int b;
5
    /* tmp 안 다른 데이터 두지 마라 — 그것도 line bouncing */
6
};

⚠️ Stack 변수 padding

1
void func(void) {
2
    alignas(64) int x;   // ← stack alignment 보장 안 됨
3
}

GCC의 -mstackrealign 옵션을 쓰거나, 해당 변수를 heap이나 static 영역에 두는 방식으로 해결합니다.

⚠️ 작은 시스템에서 over-pad

1
/* Cortex-M7 — 32 byte cache line */
2
alignas(64) int x;   // ← 32 byte로 충분

Embedded 환경에서는 cache line size를 확인한 다음 정확히 그 크기에 맞춰 align해야 합니다.

#정리

False sharing은 다른 변수가 같은 line에 있어서 coherence ping-pong이 발생하는 현상입니다.
해결책은 line size에 맞춘 alignas(64) padding입니다.
진단에는 perf c2c를 사용합니다.
Producer/consumer queue와 per-CPU counter는 기본적으로 padding을 넣어야 합니다.
True sharing은 별도의 문제이며, sharding으로 해결합니다.
Cache line size는 Cortex-M7에서 32, 대부분의 CPU에서 64, Apple M1에서 128입니다.

다음 편은 Lock Contention을 다룹니다.

#관련 항목

Embedded Performance Engineering · 32 of 57

Cache Line 최적화 — Alignment·Prefetch·False Sharing 처리

64-byte line alignment, software prefetch, false sharing 회피, SoA·AoS 선택.

2026년 4월 24일 · cache

같은 시리즈에서 이어 읽기

실전 사례 — CXL.mem 추가로 LLM inference KV cache 처리량 회복

70B 모델 KV cache가 HBM 한계를 넘어 throughput이 무너졌을 때, CXL.mem 256 GB pool 추가로 회복한 실전 케이스.

2026년 6월 16일 · cxl

같은 시리즈에서 이어 읽기

CXL 성능 프로파일링 도구 — cxl-cli·DAMON·perf-mem 활용

CXL.mem 환경 성능 도구 — cxl-cli 토폴로지·DAMON page activity·perf-mem로 보는 CXL 트래픽·numastat 통계.

2026년 6월 16일 · cxl

같은 시리즈에서 이어 읽기

False Sharing 진단 — Cache Line Ping-Pong·Padding·측정

#한 줄 요약

#메커니즘

#MESI Protocol

#측정 — 실 cycle

#Padding

#1. Per-CPU 변수

#2. Producer/Consumer Queue

#3. Spinlock 인접 데이터

#perf c2c — Cache-to-Cache 진단

#Intel VTune Memory Access

#Embedded — Cortex-A SMP

#False Sharing은 항상 나쁜가?

#Lock-free Queue 디자인

#자주 하는 실수

#정리

#관련 항목

Embedded Performance Engineering · 32 of 57

관련 글

Cache Line 최적화 — Alignment·Prefetch·False Sharing 처리

실전 사례 — CXL.mem 추가로 LLM inference KV cache 처리량 회복

CXL 성능 프로파일링 도구 — cxl-cli·DAMON·perf-mem 활용

이 글을 참조하는 글 (8)

#한 줄 요약

#메커니즘

#MESI Protocol

#측정 — 실 cycle

#Padding

#흔한 false sharing 패턴

#1. Per-CPU 변수

#2. Producer/Consumer Queue

#3. Spinlock 인접 데이터

#perf c2c — Cache-to-Cache 진단

#Intel VTune Memory Access

#Embedded — Cortex-A SMP

#False Sharing은 항상 나쁜가?

#True Sharing — 진짜 공유 시

#Lock-free Queue 디자인

#자주 하는 실수

#정리

#관련 항목

Embedded Performance Engineering · 32 of 57

관련 글

Cache Line 최적화 — Alignment·Prefetch·False Sharing 처리

실전 사례 — CXL.mem 추가로 LLM inference KV cache 처리량 회복

CXL 성능 프로파일링 도구 — cxl-cli·DAMON·perf-mem 활용

이 글을 참조하는 글 (8)