Dynamic tuning of IRQs and kthreads

[adriaan42]

For a flexible deployment of realtime applications we need tuning of IRQs and kernel threads that go beyond what TuneD currently offers:

• Tuning of individual interrupts: If the realtime application uses a device (e.g., NIC), we want to control the affinity of the corresponding interrupt. Currently, we can only control the affinities of all interrupts with one setting.
• Tuning of individual kernel threads: Example is again a NIC that can have associated NAPI threads, which we want to tune. Some of this is already possible with the scheduler plugin, but it's lacking flexibility.
• Adapt tuning dynamically: resources (isolated CPUs, NICs, ...) are allocated to apps dynamically, so we only know which IRQs and Kthreads we need to move to which CPUs at the time an app is started. Currently this can only be done statically in the profile.

The code is already there:

• add dbus commands for dynamic creation of instances #596
• Tuning of individual interrupts #580
• Tuning of individual kernel threads #628

Opening this issue to summarize and put the 3 PRs into context.

@yarda could you please comment? Is this a relevant story for TuneD in principle? Do you think it's realistic to get this integrated for the 2.23 release?

[adriaan42]

@yarda so this missed the 2.23 release (which came at a surprising time, not on the February-and-August schedule of the previous years...)

What about 2.24 then? Do we have a chance to get this in? Are there already plans for a next release date?

[adriaan42]

What about 2.24 then? Do we have a chance to get this in? Are there already plans for a next release date?

@yarda I see that you just released v2.24.0-rc1.

Does that mean the remaining PR #628 will again miss the release? I must say that this is somewhat frustrating, as it seemed to be making good progress there for a while.

[yarda]

Sorry, I understand your frustration, but I had to draft the release to be in sync with multiple projects deadlines which are out of my control. Maybe we could publish the planned release dates somewhere in advance (any tips where to publish it are welcome). I think this PR is on the good way, but I would like to do more testing. If it's blocking you, I think we could do new minor Z-stream upstream update e.g. v2.24.1 shortly.

[adriaan42]

I understand.

We're currently developing a component using these features. This work should also provide some more testing (and recently uncovered #662). Our planned release is late September/early October, and it would make my work a lot easier, if we can depend on a released version on TuneD. So if it's ok for you to have the feature in a minor release, that would be a great help.

To better track features/fixes/issues that should be addressed in upcoming releases, maybe GitHub's "Milestones" would be an easy solution?