Как измерить накладные расходы на переключение контекста очень большой программы?

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

Стоимость переключения контекста отражается в промахах кеша после повторного запуска потока. (И не позволяет OoO exec найти такое количество ILP прямо на границе прерывания). Эта стоимость более значительна, чем стоимость кода ядра, который сохраняет/восстанавливает регистры. Таким образом, даже если бы был способ измерить, сколько времени процессоры тратят на код переключения контекста ядра (это возможно с профилировщиком выборки perf record, если ваша настройка perf_event_paranoid позволяет записывать адреса ядра), это не было бы точным отражением истинного Стоимость.

Даже выполнение системного вызова имеет аналогичные (но меньшие и более частые) потери производительности из-за сериализации OoO exec, а также нарушения кэшей (и TLB). В статье Livio & Stumm есть полезная характеристика этого для реальных современных процессоров (с 2010 г.), особенно график на первой странице IPC (количество инструкций за цикл), который падает после возврата системного вызова и требует времени для восстановления: FlexSC: гибкое планирование системных вызовов с системными вызовами без исключений. (Презентация конференции: https://www.usenix.org/conference/osdi10/flexsc-flexible-system-call-scheduling-exception-less-system-calls)

Вы можете оценить стоимость переключения контекста, запустив программу в системе с достаточным количеством ядер, чтобы вообще не нуждаться в переключении контекста (например, большой многоядерный Xeon или Epyc), по сравнению с меньшим количеством ядер, но с теми же процессорами / кэши/межъядерные задержки и тд. Итак, в той же системе с taskset --cpu-list 0-8 ./program, чтобы ограничить количество ядер, которые она может использовать.

Посмотрите на общее количество использованных ЦП в секундах пользовательского пространства: большее количество — это дополнительное время ЦП, необходимое из-за замедления из-за переключения контекста. Время настенных часов, конечно, будет выше, когда одна и та же работа должна конкурировать за меньшее количество ядер, но perf stat включает выходные данные часов задачи, которые сообщают вам общее время в миллисекундах ЦП, которое потоки вашего процесса потратили на ЦП. Это было бы постоянным для того же объема работы, с идеальным масштабированием для большего количества потоков и/или для тех же потоков, конкурирующих за большее/меньшее количество ядер.

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