|
(This is not a helpful reply. I am sorry.)
You made changes to the kernel scheduling in RT, and are deciding afterwards how you will evaluate the performance? Surely, that is completely wrong.
Shouldn't you have only been doing this kind of low level hackery with a well-defined objective in mind, and then be testing whether it met the defined objective? (Well, objectives, rather than objective.)
You probably wouldn't be working on RT if interrupt performance was completely unimportant, so you would probably want to have before and after benchmarks on that.
As you've changed the scheduler, you'll probably want something related to responsiveness, but exactly what responsiveness means to you depends on whether you have interaction with humans or other machines.
Other things depend on what your app does. In general, what is it that your app does that is difficult, from a timing/performance p-o-v? Do you have a benchmark related to that/those things?
|
