I am working on an embedded application that requires realtime performance during certain periods of it's execution.
I escalate the priority of the application for approximately 150ms with a call to
sched_setscheduler( 0, SCHED_FIFO, &s ) where s.sched_priority = sched_get_priority_max(SCHED_FIFO), which returns 99.
I there after lower the scheduling priority of the application with a call to
sched_setscheduler( 0, SCHED_OTHER, &s ) where s.sched_priority = sched_get_priority_min(SCHED_OTHER).
This scheduler priority escalation/de-escalation occurs once every second.
Intermittent realtime deadline misses have manifested within my application. I would like to profile the scheduler to determine if the realtime execution periods are being preempted.
perf sched record -r 99 -R ./test_app
[ perf record: Woken up 9 times to write data ] [ perf record: Captured and wrote 10.272 MB perf.data (~448808 samples) ]
What I am looking for is a sched_switch event associated with my application with reference to a priority value of 99. As I can determine that my application should escalate it's scheduling priority n times, should I find more than n number of such events, that would imply that the realtime portion(s) of execution are being preempted.
Lots of scheduler data is send to stdout with the following command:
perf sched trace | grep test_app | grep sched_switch
I expected to find scheduler switching events mentioning a priority of 99 with:
perf sched trace | grep test_app | grep sched_switch | grep prio=99
Yet the above command returns nothing.
I am using perf version 0.0.2.PERF. Have I made incorrect assumptions with regards to the behaviour or usage of perf? If so can anyone please suggest the correct usage or other an alternative to profiling the linux realtime scheduler.
