Ответ 1
1) По умолчанию в параметре perf stat отображаются task-clock и не отображаются cpu-clock. Следовательно, мы можем сказать, что ожидаемые task-clock были гораздо более полезными.
2) cpu-clock были просто сломаны и не ремонтировались много лет. Лучше всего игнорировать это.
Исключение: при профилировании CPU или CPU - в отличие от конкретной задачи - например, perf stat -a. perf stat -a показывает cpu-clock вместо task-clock. В этом конкретном случае оба должны были быть эквивалентными. Оригинальное намерение для cpu-clock имеет больше смысла в этом случае. Таким образом, для perf stat -a вы можете просто игнорировать это различие и все равно рассматривать его как task-clock.
Если вы пишете свой собственный код, который профилирует ЦП или ЦП... может быть, будет наиболее perf stat -a следовать поведению perf stat -a... но вы можете perf stat -a на этот вопрос, чтобы объяснить, что вы делаете :-).
Re: perf: некоторые вопросы о событиях perf software
Также в настоящее время я не вижу каких-либо реальных отличий между событиями cpu-clock и task-clock. Кажется, что они оба считают время, прошедшее, когда задача выполняется на процессоре. Я ошибся?
Нет, Фрэнсис уже заметил, что, возможно, я испортил его, когда добавил материал multi-pmu, который стоит посмотреть в моем списке задач (Фрэнсис также вручил мне небольшой патчлет), но я продолжаю отвлекаться на другие вещи:/
ХОРОШО.
Имеет ли смысл корректировать период для них обоих?
Кроме того, при создании события часов задачи передача pid = -1 sys_perf_event_open() не имеет смысла, не так ли?
То же самое с часами процессора и 'pid = n': при любом значении событие измеряет настенные часы процессора.
Возможно, было бы лучше, если бы в API было предложено только одно время и внутренняя привязка этих часов к процессору или часам задач в зависимости от параметров pid или cpu?
Нет, на самом деле имеет смысл подсчитывать как процессор, так и часы задачи (задача в основном настенная).
Другими словами:
Предполагалось, что cpu-clock sleep 1 будут показывать около 1 секунды. Напротив, task-clock показывали бы близко к нулю. Было бы целесообразно использовать cpu-clock для считывания времени настенных часов. Затем вы можете посмотреть на соотношение между cpu-clock и task-clock.
После того, как они так долго были эквивалентны task-clock и не были четко документированы, даже возможно, что "исправление" существующего счетчика может вызвать регрессию в некоторой программе пространства пользователя. Если есть такая программа, Linux может не справиться с этим счетчиком. Linux, возможно, придется определить новый счетчик вместо этого.