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
16

17
* 매 access마다 *line bounces between caches* (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)