Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Device-independent, instance-specific tuning #662

Open
adriaan42 opened this issue Jul 25, 2024 · 0 comments
Open

Device-independent, instance-specific tuning #662

adriaan42 opened this issue Jul 25, 2024 · 0 comments

Comments

@adriaan42
Copy link
Contributor

adriaan42 commented Jul 25, 2024

Follow-up to #596 (comment)

There is an inconsistency in when the static tuning of an instance is applied:

  • Static tuning is only executed at startup (via instance_apply_tuning)
  • If at that time, the instance is not active (has no devices attached), static tuning is skipped
  • If devices are assigned to the instance later, it becomes active, but static tuning is not triggered
  • If the instance shuts down, it's now active, and static tuning will be unapplied
  • Same situation can happen in "reverse": If an instance starts out with devices, its static tuning will be applied. If then the devices are detached, it becomes inactive, and on shutdown its static tuning will never be unapplied.

I don't think any of the current plugins has a problem with this, but it's an issue for my PR #628, where I'm trying to use _instance_[un]apply_static to determine the number of active instances (https://github.com/adriaan42/tuned/blob/adriaan/kthreads/tuned/plugins/plugin_kthread.py#L272).

I see two possible solutions (there may be more):

  1. Always (un)apply the static instance tuning, even if the instance is inactive. This would be easy to implement, but sounds wrong.
  2. Track when an instance becomes active (first device is attached) or inactive (last device is detached) and then apply or unapply the static tuning. Since I believe adding/removing devices can be triggered by multiple threads, we'd probably need to add a lock here... so possible not so easy, but sounds a but more right than (1).
adriaan42 added a commit to adriaan42/tuned that referenced this issue Jul 25, 2024
Calls to our _instance_[un]apply_static() are unreliable [1], so we
can't use them to keep track of the active-instance count, to
start/stop the perf monitor thread on demand. Instead, this keeps
the thread running continuously.

[1] redhat-performance#662

Signed-off-by: Adriaan Schmidt <[email protected]>
adriaan42 added a commit to adriaan42/tuned that referenced this issue Oct 1, 2024
Calls to our _instance_[un]apply_static() are unreliable [1], so we
can't use them to keep track of the active-instance count, to
start/stop the perf monitor thread on demand. Instead, this keeps
the thread running continuously.

[1] redhat-performance#662

Signed-off-by: Adriaan Schmidt <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant