-
Notifications
You must be signed in to change notification settings - Fork 177
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
Tuning of individual kernel threads #628
base: master
Are you sure you want to change the base?
Conversation
c2c554a
to
1c03a83
Compare
tuned/plugins/plugin_kthread.py
Dismissed
""" | ||
def __init__(self, monitor_repository, storage_factory, hardware_inventory, device_matcher, device_matcher_udev, plugin_instance_factory, global_cfg, variables): | ||
super(KthreadPlugin, self).__init__(monitor_repository, storage_factory, hardware_inventory, device_matcher, device_matcher_udev, plugin_instance_factory, global_cfg, variables) | ||
self._has_dynamic_options = True |
Check warning
Code scanning / CodeQL
Overwriting attribute in super-class or sub-class Warning
Plugin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pattern is used in many plugins, and I don't see an easy way around it without larger refactorings.
It's OK for me, in long-term it's a candidate for rewrite/refactor, but there are other plugins using it as well. We will probably keep the idea and if we change the implementation, this could be then updated in all affected plugins the same way. |
Regarding the cgroups, there is support for cgroups v1 in the scheduler plugin and we would also like to add support for the v2 for completeness. It could be useful for somebody. It's OK if you are not using some plugin. We even wanted to add global configuration option allowing selective disablement of specific plugins in the stock profiles. |
1c03a83
to
826223f
Compare
I found the whole cgroup topic to be rather tricky, because in modern systems, SystemD is the "cgroup manager", and it owns (by convention) the cgroup tree. So any creation of new cgroups should happen via SystemD, and can then use Delegation to create further sub-groups. I've had some success with:
But simply having TuneD move processes around seems like it could have unwanted side-effects, and should be handled with care... |
826223f
to
262305b
Compare
262305b
to
f50ea9e
Compare
f50ea9e
to
55f965d
Compare
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
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 <adriaan.schmidt@siemens.com>
55f965d
to
3e91c01
Compare
#def _instance_apply_static(self, instance): | ||
# if self._instance_count == 0: | ||
# # scan for kthreads that have appeared since plugin initialization | ||
# self._kthread_scan(initial=False) | ||
# self._perf_monitor_start() | ||
# self._instance_count += 1 | ||
# super(KthreadPlugin, self)._instance_apply_static(instance) | ||
|
||
#def _instance_unapply_static(self, instance, rollback): | ||
# super(KthreadPlugin, self)._instance_unapply_static(instance, rollback) | ||
# self._instance_count -= 1 | ||
# if self._instance_count == 0: | ||
# self._perf_monitor_shutdown() |
Check notice
Code scanning / CodeQL
Commented-out code Note
In combination with #596 and #580, this PR implements the third feature needed to dynamically tune all relevant aspects of a realtime application using a dedicated HW device (typically a NIC).
Two things might need some discussion:
scheduler
plugin, but means we still need_has_dynamic_options
, which is marked as a hack in plugins/base.py. The alternative would be to have one plugin instance per "group", which would make the profiles much longer.group.ktimers=0:f:2:*:^\[ktimers
scheduler
plugin and thekthread
plugin, we'd have two threads doing the same thing. For my applications that's not a problem, because I no longer use thescheduler
plugin at all:scheduler
handles three things: IRQ affinities, kernel threads, and userland threadsirq
pluginkthread