Some enhancement ideas

[jan-kiszka]

First of all, this looks pretty much like what I was thinking of starting myself at some point. I'm specifically searching for a way to model complex workloads for regression testing and bug reproduction purposes. And that primarily for RT systems, but as those generally also contain non-RT workload, the tool should be not limited to RT. And that is what rt-app already does, nice!

Now I tried to throw a simple example at it, two RT threads simulating different lifecycle phases and different lock types, including wrong ones. But that is not possible with rt-app yet because there is only a global pi_enabled, nothing per mutex. Also, I cannot create prio-ceiling mutexes. Ideally, this tool could even model something like https://lore.kernel.org/all/[email protected]/ one day.

So, here is a first set of ideas regarding possible enhancements:

• allow to define mutex protocol per instance
• allow to join threads (would complement fork)
• allow to exit rt-app when leading threads are done (background task: loop=-1, foreground task: loop=1000 -> terminate when the latter exits)
• add support for more synchronization and event mechanisms (semaphore, select/poll/epoll, timerfd, kill/sigwait, signalfd. ...) - we even already had fun with io_uring and RT (https://lore.kernel.org/all/[email protected]/)
• also support yaml as input (json is too much typing, and workgen should be able to convert that)
• maybe call the converter from rt-app to avoid the need for a pipeline (minor usability thing)
• introduce proper schema, rather than only json-like language (only based on first impressions and own experiences with our kas tool, I might miss the real benefits of the current relaxed model)
• add support for Xenomai (https://xenomai.org), classic v3 and evl/v4 (I'll talk to the maintainer 😉)

Not only for the last point, I'll see what my colleagues and I can contribute if such extensions are considered in scope for the project. I'm also happy to split things up into multiple issues if preferred. This is really just a first brain dump.

Oh, there is one idea that goes even beyond: create workload configs from real system traces. Already discussed with several folks before and, yes, that's not a simple task. We could start from creating a rough template and let the human do more fine-tuning.

[vingu-linaro]

First of all, this looks pretty much like what I was thinking of starting myself at some point. I'm specifically searching for a way to model complex workloads for regression testing and bug reproduction purposes. And that primarily for RT systems, but as those generally also contain non-RT workload, the tool should be not limited to RT. And that is what rt-app already does, nice!

Now I tried to throw a simple example at it, two RT threads simulating different lifecycle phases and different lock types, including wrong ones. But that is not possible with rt-app yet because there is only a global pi_enabled, nothing per mutex. Also, I cannot create prio-ceiling mutexes. Ideally, this tool could even model something like https://lore.kernel.org/all/[email protected]/ one day.

So, here is a first set of ideas regarding possible enhancements:

• allow to define mutex protocol per instance
• allow to join threads (would complement fork)
• allow to exit rt-app when leading threads are done (background task: loop=-1, foreground task: loop=1000 -> terminate when the latter exits)

Isn't already what happens if you don't set a duration ? Or your background task is not the rt-app main thread but part of your use case ?

• add support for more synchronization and event mechanisms (semaphore, select/poll/epoll, timerfd, kill/sigwait, signalfd. ...) - we even already had fun with io_uring and RT (https://lore.kernel.org/all/[email protected]/)

If there are new events that you would like to be added, we can certainly discuss their inclusions

• also support yaml as input (json is too much typing, and workgen should be able to convert that)

That's something we have considered but never get anyone to implement it. We just need to ensure backward compatibility for current json file.

• maybe call the converter from rt-app to avoid the need for a pipeline (minor usability thing)
• introduce proper schema, rather than only json-like language (only based on first impressions and own experiences with our kas tool, I might miss the real benefits of the current relaxed model)
• add support for Xenomai (https://xenomai.org), classic v3 and evl/v4 (I'll talk to the maintainer 😉)

Not only for the last point, I'll see what my colleagues and I can contribute if such extensions are considered in scope for the project. I'm also happy to split things up into multiple issues if preferred. This is really just a first brain dump.

All contribution are welcome

Oh, there is one idea that goes even beyond: create workload configs from real system traces. Already discussed with several folks before and, yes, that's not a simple task. We could start from creating a rough template and let the human do more fine-tuning.

yeah, that's something we also wanted but as you said, this si complex as we want to track the behavior but not how the system impact the use case because of freq scaling increasing runtime or things like that

[jan-kiszka]

allow to exit rt-app when leading threads are done (background task: loop=-1, foreground task: loop=1000 -> terminate when the latter exits)

Isn't already what happens if you don't set a duration ? Or your background task is not the rt-app main thread but part of your use case ?

This doesn't terminate so far (yes, I'm already playing with a simple yaml converter):

global:
  lock_pages: false
  calibration: 1

tasks:
  foreground:
    loop: 1000
    sleep: 1000
  background:
    loop: -1
    sleep: 1000

Or what did you mean?

[vingu-linaro]

allow to exit rt-app when leading threads are done (background task: loop=-1, foreground task: loop=1000 -> terminate when the latter exits)

Isn't already what happens if you don't set a duration ? Or your background task is not the rt-app main thread but part of your use case ?

This doesn't terminate so far (yes, I'm already playing with a simple yaml converter):

global:
  lock_pages: false
  calibration: 1

tasks:
  foreground:
    loop: 1000
    sleep: 1000
  background:
    loop: -1
    sleep: 1000

Or what did you mean?

Okay, by background task, I meant the main thread in rt-app that starts and stops the sequence not a thread created for the use case.
This is should be doable with a "exit" event that would trigger same action as global duration