Я работаю над встроенным приложением, которое требует производительности в реальном времени в течение определенных периодов его выполнения.
Я увеличиваю приоритет приложения примерно на 150 мс с вызовом
sched_setscheduler (0, SCHED_FIFO, & s), где s.sched_priority =
sched_get_priority_max (SCHED_FIFO), который возвращает 99.
Я там после понижения приоритета планирования приложения с вызовом на
sched_setscheduler (0, SCHED_OTHER, & s), где s.sched_priority =
sched_get_priority_min (SCHED_OTHER).
Это повышение приоритета планировщика / деэскалация происходит один раз в секунду.
Периодические пропуски сроков в реальном времени проявились в моей заявке. Я хотел бы профилировать планировщик, чтобы определить, выгружаются ли периоды выполнения в реальном времени.
запись перфокарты -r 99 -R ./test_app
[perf запись: 9 раз просыпался для записи данных] [perf запись:
Захвачено и записано 10.272 МБ perf.data (~ 448808 образцов)]
Я ищу событие sched_switch, связанное с моим приложением со ссылкой на значение приоритета 99. Поскольку я могу определить, что мое приложение должно повысить свой приоритет планирования n раз, я должен найти больше n таких событий , это означало бы, что часть (и) выполнения в реальном времени выгружается.
Многие данные планировщика отправляются на стандартный вывод с помощью следующей команды:
след от перфокарты | grep test_app | grep sched_switch
Я ожидал найти события переключения планировщика с приоритетом 99:
след от перфокарты | grep test_app | grep sched_switch | grep prio = 99
Тем не менее, приведенная выше команда ничего не возвращает.
Я использую перф версию 0.0.2.PERF. Я сделал неправильные предположения относительно поведения или использования perf? Если да, то кто-нибудь может предложить правильное использование или другую альтернативу профилированию планировщика реального времени linux.