Refactor dynamic tuning and add per-plugin global configuration #626
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
zacikpa
force-pushed
the
per-plugin-dynamic
branch
2 times, most recently
from
3e17127
to
c513217
Compare
zacikpa
force-pushed
the
per-plugin-dynamic
branch
5 times, most recently
from
c061d7e
to
4c3020c
Compare
|
Please resolve conflicts. |
zacikpa
force-pushed
the
per-plugin-dynamic
branch
2 times, most recently
from
6d45946
to
d61116b
Compare
Add a new global option "dynamic_plugins" which can be used to globally enable dynamic tuning only for specific plugins. Also unify the behavior of the "dynamic" profile option for plugins with dynamic capabilities. All such plugins now have this option and it is set to True by default. Dynamic tuning is then enabled for a specific plugin if it is allowed both globally and locally.
Let plugins choose between the default (periodic) dynamic tuning and their own implementation. If a plugin uses the default periodic tuning, it must implement the update_tuning method which is then periodically called by the main daemon thread. Non-periodic implementations may, e.g., start their own threads.
Remove the "runtime" option from the scheduler plugin and integrate its functionality into dynamic tuning. Currently, the scheduler plugin is the only dynamic plugin with its own implementation of dynamic tuning (not initiated periodically by the main daemon thread). Adjust default global configuration so that dynamic tuning is enabled by default, but only for the scheduler plugin.
zacikpa
force-pushed
the
per-plugin-dynamic
branch
from
d61116b
to
7476d32
Compare
Done. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR, I add a global per-plugin configuration of dynamic tuning, which works as follows:
dynamic_tuningoption stays as it is - it can be used to globally enable or disable dynamic tuning in all plugins.dynamic_tuningis on, one can use the newdynamic_pluginsoption to restrict the set of plugins which can perform dynamic tuning. For instance, settingdynamic_plugins=scheduler,diskenables dynamic tuning only for the two plugins.dynamic=0in the profile configuration. This now works for all plugins with dynamic capabilities.Secondly, I integrated the "runtime" functionality of the scheduler plugin under dynamic tuning. To do so, we need to distinguish between dynamic plugins that are updated periodically by the main daemon thread (currently, all except the scheduler plugin) and dynamic plugins that implement their tuning in their own thread.
The changes required quite a bit of refactoring. I believe the code could be made even cleaner by creating a separate subclass of
Pluginfor the dynamic plugins, but that would require even more massive refactoring, so I'm not sure if it's worth doing at this point.