я должен привязать крутящуюся нить к определенному ядру?

Выполнение потока, привязанного к одному ядру, дает лучшую задержку для этого потока в большинстве случаев, если это самая важная вещь в вашем коде.

Причины (R)

• ваш код, скорее всего, будет в вашем iCache
• предикторы ветвления настроены на ваш код
• ваши данные, вероятно, будут готовы в вашем dCache
• TLB указывает на ваш код и данные.

Пока не

• Your running a SMT sytem (ex. hyperthreaded) in which case the evil twin will "help" you with by causing your code to be washed out, your branch predictors to be tuned to its code and its data will push your out of the dCache, your TLB is impacted by its use.
  • Cost unknown, each cache misses cost ~4ns, ~15ns and ~75ns for data, this quickly runs up to several 1000ns.
  • Он сохраняет по каждой причине, упомянутой выше, которая все еще существует.
  • Если злой близнец также просто раскручивает, затраты должны быть намного ниже.
• Or your allowing interrupts on your core, in which case you get the same problems and
  • your TLB is flushed
  • вы берете удары 1000 нс-20000 нс на переключатель контекста, большинство из них должно быть в нижнем конце, если драйверы хорошо запрограммированы.
• Or you allow the OS to switch your process out, in which case you have the same problems as the interrupt, just in the hight end of the range.
  • switching out could also cause the thread to pause for the entire slice as it can only be run on one (or two) hardware threads.
• Or you use any system calls that cause context switches.
  • No disk IO at all.
  • только асинхронный ввод-вывод остальное.
• наличие большего количества активных (не приостановленных) потоков, чем ядер, увеличивает вероятность проблем.

Поэтому, если вам нужна задержка менее 100 нс, чтобы ваше приложение не взорвалось, вам необходимо предотвратить или уменьшить влияние SMT, прерываний и переключения задач на ваше ядро. Идеальным решением была бы Операционная система реального времени со статическим планированием . Это почти идеально подходит для вашей цели, но это новый мир, если вы в основном занимались серверным и настольным программированием.

Недостатки привязки потока к единственному ядру:

• It will cost some total throughput.
  • as some threads that might have run if the context could have been switched.
  • но в этом случае важнее время ожидания.
• If the thread gets context switched out it will take some time before it can be scheduled potentially one or more time slices, typically 10-16ms, which is unacceptable in this application.
  • Locking it to a core and its SMT will lessen this problem, but not eliminate it. Each added core will lessen the problem.
  • установка более высокого приоритета уменьшит проблему, но не устранит ее.
  • расписание с SCHED_FIFO и наивысшим приоритетом предотвратит большинство переключений контекста, прерывания могут вызывать временные переключения, как и некоторые системные вызовы.
  • Если у вас есть установка с несколькими процессорами, вы можете получить исключительное право собственности на один из процессоров через процессор. Это предотвращает его использование другими приложениями.

Использование pthread_setschedparam с SCHED_FIFO и наивысшим приоритетом, выполняющимся в SU и блокировкой он до мозга костей и его злой двойник должны обеспечивать лучшую задержку из всех перечисленных, только операционная система реального времени может исключить все переключения контекста.

Другие ссылки:

Обсуждение прерываний.

Ваша Linux может принять вызов sched_setscheduler с помощью SCHED_FIFO , но для этого требуется, чтобы у вас был свой собственный PID, а не только TID, или чтобы ваши потоки выполняли совместную многозадачность.
Это может быть не идеально, поскольку все ваши потоки будут переключаться только «добровольно», что лишает ядро ​​гибкости для его планирования.

Межпроцессное взаимодействие в 100 нс

Привязка задачи к конкретному процессору обычно дает лучшую производительность для задачи. Но при этом необходимо учитывать множество нюансов и затрат.

Когда вы устанавливаете привязку, вы ограничиваете выбор расписания операционной системы. Вы увеличиваете конкуренцию за ЦП для оставшихся задач. Таким образом, это затрагивает ВСЕ в системе, включая саму операционную систему. Вы также должны учитывать, что если задачи должны взаимодействовать через память, а привязки установлены для процессоров, которые не используют общий кеш, вы можете резко увеличить задержку для взаимодействия между задачами.

Одна из основных причин, по которой установка сродства к процессору задачи является полезной, заключается в том, что она дает более предсказуемое поведение кеша и tlb (буфер обратного преобразования). Когда задача переключает процессор, операционная система может переключить его на процессор, у которого нет доступа к кешу последнего процессора или tlb. Это может увеличить количество промахов в кэше для задачи. Это особенно проблема взаимодействия между задачами, так как требуется больше времени для взаимодействия между кешами более высокого уровня и, наконец, с памятью. Для измерения статистики кеширования в Linux (производительности в целом) я рекомендую использовать perf.

Лучшее предложение - действительно измерить, прежде чем пытаться исправить сходство. Хороший способ количественно оценить задержку - использовать инструкцию rdtsc (по крайней мере, на x86). Это считывает источник времени процессора, что обычно дает наивысшую точность. Измерение событий дает точность примерно наносекунду.

volatile uint64_t rdtsc() {
   register uint32_t eax, edx;
   asm volatile (".byte 0x0f, 0x31" : "=d"(edx), "=a"(eax) : : );
   return ((uint64_t) edx << 32) | (uint64_t) eax;
}

• примечание - инструкция rdtsc должна быть объединена с ограничителем нагрузки, чтобы гарантировать выполнение всех предыдущих инструкций (или используйте rdtscp)
• также обратите внимание - если rdtsc используется без постоянного источника времени (в linux grep constant_tsc /proc/cpuinfo, вы можете получить ненадежные значения при изменении частоты и если задача переключает ЦП (источник времени)

Итак, в целом, да, установка привязки дает более низкую задержку, но это не всегда верно, и когда вы это делаете, это очень дорого обходится.

Дополнительное чтение ...

• Перечень топологии процессоров с архитектурой Intel 64
• Что каждый программист должен знать о памяти (части 2, 3, 4, 6 и 7)
• Справочник разработчика программного обеспечения Intel ( Том 2A / 2B)
• Захватывающие и освобождающие ограждения
• TCMalloc

Привязка потока к определенному ядру, вероятно, не лучший способ выполнить работу. Вы можете это сделать, это не повредит многоядерному процессору.

На самом деле лучший способ уменьшить задержку - повысить приоритет процесса и потока (ов) опроса. Обычно ОС прерывает ваши потоки сотни раз в секунду и позволяет другим потокам работать некоторое время. Ваш поток может не работать несколько миллисекунд.

Повышение приоритета уменьшит эффект (но не устранит его).

Подробнее о SetThreadPriority и SetProcessPriorityBoost. В документации есть некоторые детали, которые вам нужно понять.

Я столкнулся с этим вопросом, потому что имею дело с той же проблемой дизайна. Я создаю HFT-системы, в которых каждая наносекунда на счету. Прочитав все ответы, я решил реализовать и протестировать 4 разных подхода.

• busy wait with no affinity set
  • busy wait with affinity set
  • образец наблюдателя
  • сигналы

Неизменным победителем стал «Ожидание в ожидании с набором аффинити». Насчет этого сомнений нет.

Теперь, как многие отмечали, не забудьте оставить пару ядер свободными, чтобы ОС могла работать свободно.

На данный момент меня беспокоит только то, есть ли какой-либо физический ущерб для тех ядер, которые работают на 100% в течение нескольких часов.

Это просто глупо. Все это снижает гибкость планировщика. Если раньше он мог запускать его на любом ядре, которое считал лучшим, теперь он не может. Если планировщик не был написан идиотами, он переместил бы поток на другое ядро ​​только в том случае, если бы у него была для этого веская причина.

Итак, вы просто говорите планировщику: «Даже если у вас есть действительно веская причина для этого, все равно не делайте этого». Почему ты так сказал?