Координирование времени от / sys / kernel / debug / tracing в Ubuntu - PullRequest
1 голос
/ 18 января 2012

Я пытаюсь собрать данные из нескольких источников на компьютере с Ubuntu 10.10 программным способом о производительности программы. Для всех других моих источников я смог собрать их, используя инструкцию RDTSC x86, а затем масштабировать их, используя gettimeofday, чтобы преобразовать в секунды в абсолютном времени. Однако, когда я начинаю пытаться согласовать эти источники данных с выводом выполнения трассировки sched_switch в / sys / kernel / debug / tracing, я сталкиваюсь с проблемой, поскольку вывод, который я вижу, происходит в секундах и микросекундах с некоторого неизвестного времени.

Шаги, которые я уже сделал:
1. Я определил, что ядро ​​Linux внутренне также использует RDTSC, но добавляет некоторое смещение, которое оно собирает, но у меня, похоже, нет возможности получить его. Это делается также для каждого ядра, что означает, что мне придется попробовать все четыре ядра и определить лучшее, что кажется плохим решением этой проблемы.
2. Я пытался преобразовать RDTSC раз вокруг включения регистрации, чтобы увидеть, является ли хотя бы само преобразование согласованным (то есть некоторое постоянное смещение), но масштаб, кажется, не остается постоянным на протяжении всего цикла.
3. clock_gettime (CLOCK_MONOTONIC, ...), похоже, имеет очень похожее значение, но всегда отключается на неприемлемую величину (около полсекунды) и тоже не выглядит полностью согласованным.

Если я могу изменить то, как мои другие источники данных собирают свое время на то, что необходимо (при условии, что это не сильно повышает производительность), как я должен собирать время, чтобы координировать время между трассировкой и временем, которое я собираю? Есть какой-то способ изменить вывод на RDTSC, так что я могу просто использовать это, или есть системный вызов, который я могу сделать, чтобы получить то же время, что и вывод для трассировки? Заранее спасибо за любую помощь.

Ответы [ 2 ]

0 голосов
/ 13 марта 2012

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

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

0 голосов
/ 07 февраля 2012

RDTSC не является популярной инструкцией. Есть некоторые проблемы при его использовании, некоторые события, такие как гибернация, сбрасывают счетчики. Другим распространенным источником проблем являются динамические тактовые частоты процессора. Есть хорошая статья, сравнивающая rdtsc и hpet:

http://aufather.wordpress.com/2010/09/08/high-performance-time-measuremen-in-linux/

Чтобы проверить точность rdtsc, я измеряю, сколько тактов он считает за одну секунду, и сравниваю его с заявленными тактовыми частотами процессора. Работает только при отключенных динамических часах процессора. См:

https://github.com/petersenna/rdtscbench

...