Проодолжим, мне с вами интересно.
Прокмон мне был нужен не для записи времени событий, а для просмотра результатов выполнения некоторых апишных вызовов. Соответственно, винда сама считает очень много статистики, но вам не показывает.
А вот procexplorer или process hacker все интересные данные уже выводят.

Я из прокмона смотрел именно использованное время в режиме пользователя и ядра. Ядерное время не выходило за рубеж нескольких миллисекунд, поэтому смысла его считать его было бессмысленно.
Меня из всей деятельности интересует именно увеличение времени работы в режиме пользователя, так как дополнительной полезной работы поток не выполняет. С большой долей вероятности это дополнительное время возникает из-за простоев в ожидании данных.
Смотрите, давайте создадим модель, описывающее время выполнения.
Есть некоторый объем процессорных инструкций, допустим он постоянен. Соответственно, его время выполнения (без учета ожидания данных) T_{истинное}. Оно никак не изменится в пределах наблюдений на одном процессоре.
Далее, у нас появляются некоторые задержки в обработке из-за ожидания данных. Очевидно, эти задержки не могут быть отрицательными. Соответственно, в пользовательском режиме поток проведет T_{usermode}=T_{истинное}+T_{задержки данных}
Продолжим, для определения реального времени, которое пользователь будет ждать до завершения вычислений, у нас возникает еще две дополнительные задержки:
1) Задержка работы планировщика, когда ядро уже выделено другому потоку. T_{планировщика}. В случае affinity = off и низкой фоновой загрузки процессора оно стремится к нулю.
2) Задержка главного потока. T_{main delay}. Сейчас ей управляете вы. Если бы не нужно было обрабатывать пользовательский ввод - можно было бы легко решить использованием posix barrier, он дает погрешность меньше миллисекунды в большинстве случаев.
Также должно быть очевидно, что эти задержки неотрицательны.
Соотвественно T_{realtime}=T_{usermode}+T_{планировщика}+T_{main delay}

Но как разработчику ПО для восоконагруженных систем, меня больше интересует T_{usermode}, в котором есть только одна погрешность. И ей то я и хочу померять.

А для этого надо провести следующие тесты:
1) Запуск с affinity на 1 ядро.
2) Запуск с affinity на 2 ядра из одного CCX (для измерения дополнительных задержек из-за эксклюзивных кешей).
3) Запуск с affinity на 2 ядра из разных CCX (для измерения задержек из-за IF)
Ну и для тредрипперов
4) Запуск с affinity на 2 ядра из разных зиппелинов (тест задержек при доступе между кристаллами)
5) В случае, если в 4-х кристальном тредрипере будут каналы памяти только в двух кристаллах, то еще замерить время с affinity на 1 ядро из кристаллов с и без доступа к памяти.

Тест без affinity это тест с affinity на все ядра. И даст он нам результаты между 2 и 3 тестами.

У вас нет возможности пропихнуть в SetThreadAffinityMask пользовательский ввод?