Ложное разделение cache line

Ложное разделение (false sharing) возникает, когда разные ядра часто записывают в независимые переменные, но эти переменные лежат в одной cache line. Согласованность кэшей поддерживается на гранулярности линии, а не отдельного поля: перед записью ядро получает линию в состояние exclusive/modified, и копии на других ядрах инвалидируются. Логически данные не разделены, физически — постоянно «переезжают» между кэшами.

Зачем это на интервью

Тема проверяет, умеете ли вы объяснять плохое масштабирование CPU-bound кода без мифа «виноват mutex». В Go это встречается в per-worker счётчиках, shard-структурах, метриках и очередях: после добавления workers throughput перестаёт расти, а профиль показывает мало блокировок. Хороший ответ связывает layout данных, паттерн записи, cache-coherence traffic и измерение.

Минимум для E4

• Знать, что cache line — единица кэширования и coherence; её размер зависит от платформы, поэтому не следует вшивать «64 байта» как универсальную гарантию.
• Отличать true sharing (ядрам действительно нужен один изменяемый объект) от false sharing (поля независимы, но соседствуют в линии).
• Объяснять, почему частые конкурентные записи особенно вредны; параллельное чтение одной линии обычно не вызывает такого ping-pong.
• Предлагать исправление только после профилирования: изменить ownership, sharding/layout, batching или добавить padding с проверкой результата.

Углубление для E5/Senior

Coherence — не общий «кэш процессора»

У каждого core есть близкие private-кэши, а общий уровень кэша и межъядерная сеть имеют свою топологию. Протоколы семейства MESI/MOESI поддерживают согласованность линий. Когда core A хочет записать линию, находящуюся и у core B, он должен получить право на запись; B теряет или отдаёт свою копию. При чередовании записей одна линия может мигрировать между сокетами и NUMA-узлами, что заметно дороже простого попадания в L1.

False sharing не требует data race. Например, каждый worker может иметь собственный uint64, а программа остаётся корректной. Проблема — производительность: независимость алгоритма потеряна на уровне размещения. Атомарные операции не устраняют её: они делают доступ корректным, но всё ещё требуют exclusive ownership той же линии и могут добавить барьеры памяти.

Почему padding — средство, а не диагноз

В примере ниже slots[i] могут оказаться рядом. Число, кратное предполагаемой линии, не даёт переносимой гарантии: нужны alignment, реальный layout, версия компилятора и целевая архитектура. В Go для типовых runtime-структур иногда применяют golang.org/x/sys/cpu.CacheLinePad, но сначала надо убедиться, что рост памяти и ухудшение locality остальных данных оправданы.

// Плохой кандидат: разные goroutine часто пишут соседние counters.
type slot struct { count uint64 }
 
// Возможный эксперимент, не контракт о размере линии.
type paddedSlot struct {
    count uint64
    _     [56]byte
}

Часто лучше изменить модель: worker локально накапливает значение и редко отправляет batch агрегатору; один владелец обновляет состояние; shard выбирается по ключу запроса, а не по номеру core. Padding большого массива повышает memory footprint, pressure на cache/TLB и может сделать последовательный обход хуже.

Диагностика и топология

Симптомы полезны только как гипотеза: throughput плохо растёт с числом CPU, CPU busy, mutex/block profile спокойны, а изменение placement полей резко меняет результат. На Linux perf stat может показать рост cache-to-cache/coherence-событий, но доступные названия зависят от CPU и ядра. perf c2c способен подсветить contested lines на поддерживаемых системах. Сравнивайте baseline и вариант под закреплённой нагрузкой; заранее проверяйте доступные события через perf list.

На NUMA эффект может усилиться: перенос линии между узлами дороже локального. Но закреплять affinity или отключать migration без измерения опасно: можно создать дисбаланс, ухудшить работу GC и скрыть системную причину. В отчёте нужны topology, нагрузка, число потоков, p95/p99, throughput и доверительный диапазон нескольких запусков.

Ключевые понятия

Понятие	Суть	Не путать с
Cache line	Гранула перемещения и coherence между кэшами	Размером отдельной переменной
True sharing	Несколько ядер изменяют один логический объект	Ошибкой синхронизации автоматически
False sharing	Независимые writable-данные попали в одну линию	Data race
Cache-coherence traffic	Обмен/invalidation линий для согласованности	Обычным cache miss от чтения памяти
Padding	Искусственное разнесение объектов в памяти	Универсальным ускорением

Типовые вопросы

1. Почему false sharing возможен без data race?
   • Гонки определяются доступом к одному логическому адресу без синхронизации. False sharing касается разных адресов, объединённых одной cache line; код может быть корректным, но плохо масштабироваться.
2. Почему атомик не решает проблему?
   • Atomic обеспечивает корректность и порядок для одного значения, но запись всё равно требует владения линией. Несколько atomics в одной линии могут сильнее гонять её между ядрами.
3. Всегда ли запись в соседние поля вредна?
   • Нет. Нужны конкурентные частые записи с разных CPU. Последовательная работа одного core или read-mostly данные обычно не дают этого эффекта.
4. Как доказать, что виновато именно размещение?
   • Стабилизировать workload и измерить исходный layout против варианта с разнесением/локальной агрегацией; подтвердить улучшение throughput и tail latency, а не только один счётчик hardware events.
5. Почему нельзя бездумно добавить 64 байта padding?
   • Размер и alignment не универсальны, а память растёт. Для больших структур это ухудшает cache locality и TLB; сначала нужно подтвердить bottleneck.
6. Чем false sharing отличается от lock contention?
   • Lock contention — ожидание конкретного механизма синхронизации. При false sharing ожидания lock может не быть; ограничение создаёт coherence-протокол и placement данных.

Практика

• Микробенчмарк счётчиков. Напишите Go benchmark с N goroutine: каждая инкрементирует свой элемент компактного массива, затем вариант с разнесёнными элементами и вариант с локальным счётчиком + редукцией.
  • Критерии готовности: есть -cpu=1,2,4,..., фиксированная работа на goroutine, b.ReportAllocs(), таблица ops/s минимум из пяти запусков и объяснение, какой вариант меняет layout, а какой ownership.
• Профиль системного эффекта. На Linux снимите baseline и лучший вариант через perf stat с доступными cache/coherence событиями; при поддержке выполните perf c2c.
  • Критерии готовности: приложены точная команда, CPU-модель, список реально доступных событий, throughput и p99; отсутствующие события отмечены как ограничение, а не выдуманы.
• Решение production-сценария. Спроектируйте метрику запросов с высокой частотой обновления на 32 workers.
  • Критерии готовности: описаны владелец данных, flush/aggregation interval, предел памяти, поведение при shutdown и критерий rollback, если p99 не улучшился.

Частые ошибки и ловушки

• Называть любую плохую параллельную производительность false sharing без baseline и профиля.
• Путать ложное разделение с race condition и заменять layout mutex-ом, увеличивая contention.
• Считать, что все CPU и все Go targets имеют cache line ровно 64 байта.
• Применять padding к hot и cold полям одновременно, раздувая рабочий набор.
• Оценивать только среднее время: coherence bursts могут ухудшать tail latency.

Связанные темы

Модуль Foundations · Планирование CPU · Throughput и tail latency · Профилирование производительности · Go

Источники

• Intel, Intel 64 and IA-32 Architectures Optimization Reference Manual, разделы о cache coherence и false sharing.
• AMD, Software Optimization Guide for AMD Family Processors, разделы о cache hierarchy и NUMA.
• Linux perf c2c documentation и perf list для доступных на конкретной машине событий.
• Go package golang.org/x/sys/cpu, документация CacheLinePad.