Предложение решения (кратко)
- Топология: 64 ядра = $...64...$. Каждое ядро — приватные L1 I/D и приватный L2; L3 — баночный, разделённый на $...8...$ банков по $...8...$ ядер (или $...16...$ банков по $...4...$ — в зависимости от NoC). Между банками NoC/mesh.
- Протокол когерентности: директори-основанный invalidate-протокол с состояниями MOESI на уровнях L1/L2; централизованная (распределённая) директория на банковом L3 (спарс- или бит-вектор).
- Политики: write-invalidate; кэш-кэш передачи при состоянии O (owner); LLC — либо инклюзивный для упрощения инвалидаций, либо эксклюзивный для большей емкости с директори-информацией (рекомендация — банковый инклюзивный L3 для простоты реализации).
- Меры против false sharing: программные (паддинг, выравнивание на строку), компиляторные оптимизации, аппаратные (sub-blocking/sector-caches или мелкая гранулярность коэрентности), detection tools.
Аргументы выбора MOESI vs MESI
- MESI: состояния {M,E,S,I}. Простее. Для записи необходимо получить эксклюзивный доступ (обычно через память или invalidate).
- MOESI: добавляет состояние O (Owner) — позволяет передавать модифицированные данные напрямую из чужого кэша без записи в память.
- Для $...64...$-ядерной системы с банковым L3 и большим объёмом кэш-кэш обменов MOESI предпочтительнее, потому что:
- уменьшает обращения к памяти (передача dirty-строки напрямую), снижает латентность промахов и пропускную способность памяти;
- но увеличивает сложность машины состояний и логику переходов, требует отслеживания владельца.
- Если система очень чувствительна к hardware-complexity/verification, можно выбрать MESI; если важна пропускная способность и уменьшение DRAM трафика — MOESI.
Детали реализации директории и скалируемости
- Директори: банковая, хранится в L3-банке, каждая линия имеет либо бит-вектор шеров (до $...64...$ бит), либо компактные структуры (pointer lists, sparse directories). Выбор: бит-вектор для простоты/скорости; sparse/limited для экономии ёмкости.
- Broadcasts минимизировать (нет глобального шины): запросы идут к директории соответствующего L3-банка; директория посылает invalidations/forwarding.
- NoC: mesh с приоритезацией запросов на кэш-кэш передачи; маршрутизация локальных банков быстрее.
False sharing — что это и как минимизировать
- Определение: когда независимые переменные, используемые разными потоками, находятся в одной кэш-строке (например, размер строки $...64$ байта), и модификации одной переменной вызывают лишние инвалидации/рефреши для других потоков.
- Программные методы:
- выравнивание и паддинг структур (align + pad до $...64...$ байт), разнесение горячих переменных в разные строки;
- приватизация данных (каждому потоку свои буферы), агрегирование обновлений (batching), использование локальных буферов и периодическая агрегация;
- изменение макета памяти (SoA вместо AoS), использование атомарных/lock-free структур для мелких счетчиков.
- Аппаратные/микроархитектурные методы:
- sub-blocking / sector caches: разбить линию на сектора (например $...16$-байт сектора в строке $...64$ байта) и поддерживать битовую валидность/грязность на сектор — снижает ложное шаринг, но увеличивает теги/сложность;
- word-level или byte-write tracking (дорого);
- snoop filters / sharer cache для уменьшения широких инвалидаций.
- Инструменты: профайлеры false sharing для выявления проблем в коде.
Влияние на задержку, пропускную способность и энергопотребление
- Задержка (latency):
- L1 hit остаётся минимальной: типично ~$...1$–$...4$ циклов (зависит от реализации).
- L2 hit: промежуточная задержка ~$...6$–$...20$ циклов.
- L3 local-bank hit: ~$...20$–$...60$ циклов.
- Кэш-кэш transfer (при MOESI, локально/в пределах банка) обычно быстрее, чем уход в DRAM: уменьшает полный miss latency относительно fetch-from-memory (DRAM ~$...100$–$...300$ циклов).
- Директория добавляет несколько циклов на обработку/lookup и сетевую передачу; но избегает широких broadcast, поэтому на больших масштабах общая задержка ниже, чем при snoop-bus.
- Пропускная способность (bandwidth):
- MOESI снижает DRAM-выводимый трафик за счёт кэш-кэш передач. Это повышает эффективную пропускную способность системы памяти и уменьшает contention на DRAM.
- Банковая L3 + директория улучшает масштабируемость пропускной способности NoC и L3, но требует балансировки банков (bank conflicts влияют на throughput).
- Sub-blocking уменьшает лишний трафик при ложном шаринге, улучшая пропускную способность.
- Энергопотребление:
- Меньше обращений к DRAM и fewer memory writes при MOESI → экономия энергии (DRAM access дорог).
- Но MOESI и директори-логика увеличивают динамическую/статическую сложность L3 и когерентности → небольшое увеличение энергопотребления на контроллеры/теги.
- Sub-blocking и дополнительные теги/битсы повышают area и leakage. Баланс: net energy часто улучшается при MOESI + директории для реальных рабочих нагрузок с шарингом, особенно при высоком DRAM-access cost.
Примеры ориентировочной эффективности (оценочно)
- В рабочих нагрузках с интенсивным кэш-кэш шарингом MOESI может сократить DRAM-трафик и miss-latency на $...20$%–$...50$% в сравнении с MESI (зависит от приложения).
- Sub-blocking может снизить лишние invalidations при false sharing до $...30$%–$...70$% для подходящих паттернов, но добавляет $...5$%–$...15$% к area/energy на кеш-контроллеры (оценочно).
Рекомендации по внедрению
- Использовать директори-основанный invalidate MOESI с банковым L3 и NoC (mesh) для масштабируемости при $...64...$ ядрах.
- Поддержать кэш-кэш forwarding (Owner) и write-invalidate.
- Ввести софт- и компиляторно-уровневые меры против false sharing (паддинг, приватизация), а для критичных приложений — аппаратное sub-blocking как опцию.
- Применять sparse директорию или гибридный бит-вектор/pointer подход для экономии памяти директории.
- Профилировать реальные приложения и настраивать число банков L3 / политику инклюзивности по результатам.
Короткое резюме
- Для $...64...$-ядерной системы оптимально: банковый L3 с распределённой директори и MOESI (invalidate + owner forwarding) — лучший компромисс между задержкой, пропускной способностью и уменьшением DRAM-трафика при приемлемой сложности реализации; false sharing устранять в первую очередь программно, а при необходимости дополнять аппаратными техниками (sub-blocking).