kernel ftracer и полный граф вызовов

В qemu обещали запилить, но пока — увы.

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

> позволяет получить только ограниченный размер отрезка

времени (несколько секунд)

почему это??? просто читай из trace_pipe.

или я вопроса не понял?

почему это??? просто читай из trace_pipe.

спасибо, кажется это - то что надо
в понедельник буду пробовать

LTTng

trace_pipe почти подходит, но есть несколько проблем:
1) забирать данные из trace_pipe (т.е. записывать в файл) надо с большой скоростью, иначе при переполнении кольцевого буфера trace будут теряться вызовы функций.
2) объем информации слишком большой, т.к. многократно повторяются уже записанные комбинации «вызываемая_функция <-вызывающая_функция». Желательно чтобы повторной записи не происходило. Возможно как-то можно доработать механизм фильтрации. Пока использовать его не получается.
2) использование троссировщика и снятие данных троссировки добавляет в ядро функциональность, которая изначально отсутствует в исследуемой системе. В идеале, динамический граф вызовов лучше было бы получать внешними средствами (отладчиком или виртуальной машиной).

Спасибо большое за ответы. Не ожидал, что в этом кто-то рубит.

> 1) забирать данные из trace_pipe (т.е. записывать в файл)

надо с большой скоростью

ото ж ;)

2) объем информации слишком большой, т.к. многократно

повторяются уже записанные комбинации

хмм. тогда я не понимаю, что тебе нужно...

«вызываемая_функция <-вызывающая_функция».

btw, там graph можно включить

2) использование троссировщика и снятие данных троссировки

не надо меня путать, это уже 3 ;)

добавляет в ядро функциональность, которая изначально

отсутствует в исследуемой системе.

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

В идеале, динамический граф вызовов лучше было бы

это вряд ли.

ты не мог бы подробнее обьснить, что тебе на самом деле
нужно? насколько я понимаю, единственная проблема, это
как-то сохранить выхлоп, и по возможности отфильтровать
работу этого сохранения. наверное, можно даже написать
свой tracer, который как-то передает данные из guest в
host (если мы гоняем это под kvm), не знаю.

есть еще trace-cmd frontend, см
http://git.kernel.org/?p=linux/kernel/git/rostedt/trace-cmd.git
я его не пробовал, может быть там что полезное есть.
по крайней мере, он (iirc) читает ring buffer «прямо» из
kernel через splice.

Задача: Показать, что статический граф вызовов функций ядра 2.6. и динамический совпадают. Если совпадают не полностью обосновать почему. Потери вызовов при динамическом анализе при этом не желательны, т.к. затрудняют обоснование отличий. Наличие в динамическом графе вызовов функций подсистемы троссировки, а также вызовов инициированных снятием данных троссировки, нежелательно по той-же причине. Другими словами чем сильнее набор функций и функциональность анализируемой системы (с троссировкой)отличается от исходной тем хуже.

ftrace_graph не позволяет получить полный динамический граф вызовов функции. Каждая запись - это текущий граф. Полный динамический граф можно получить только анализируя лог. При этом объем лога в десятки раз больше чем при использовании ftrace (8 ГБ - примерно 20 минут работы ядра, т.е. для ftrace_graph получиться около 80ГБ). Время тестирования должно быть по крайней мере 2 часа. Поэтому проще минимизировать количество данных, формируемых ftrace (например, выводить только адреса функций (func_addr <- parent_func_addr) и отфильтровать повторы (пока не получилось), т.е. если в кольцевом буфере уже есть текущая пара func_addr <- parent_func_addr ничего не протоколировать). Парсить log и забивать данные в базу тоже проще.

Можешь поподробнее объяснить что значит («он (iirc) читает ring buffer „прямо“ из kernel через splice»)

На самом деле большое спасибо всем, кто отвечал. Вы мне очень помогли. По крайней мере направили. Результат нужен достаточно быстро, так что пока забью в базу log ftrace-a. Будет время посмотрю LTTng и trace-cmd.

> Показать, что статический граф вызовов функций ядра 2.6. и динамический совпадают.

А как ты получил статический граф?

> Показать, что статический граф вызовов функций ядра 2.6.

и динамический совпадают.

а. тогда не знаю.

и присоединяюсь к вопросу, заданному tailgunner.

кроме того, я вообще не очень понимаю, что такое
«статический граф» в данном случае.

Наличие в динамическом графе вызовов функций подсистемы

троссировки

ну, это, вроде, не проблема, можно отфильтровать

При этом объем лога в десятки раз больше чем при

использовании ftrace

конечно. кстати, я забыл упомянуть про trace_pipe_raw,
он намного «меньше», но нужно парсить самому.

то значит («он (iirc) читает ring buffer „прямо“ из

kernel через splice»)

вот даже не знаю, как. sys_splice() позволяет (в том
числе) более эффективно перекидывать данные в другой fd.
те trace-cmd может слать содержимое trace-buffer «прямо»
в socket, к примеру.

еще раз: могу соврать, я его не смотрел.