-
Notifications
You must be signed in to change notification settings - Fork 190
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
cpu_plugin: Add property "uncore_max_freq_khz" #576
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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.
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.
Allowing per-cpu configuration of something that cannot be configured for individual cpus does not make sense to me. The uncore frequency is configurable for each package/die combination - not for individual cpus.
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.
I generally agree with that. From simplicity perspective I think better would be separate plugin that allow configure individual uncore's based on name in sysfs i.e. package_NN_die_MM or uncoreNN. I'm ok to implement such plugin, if that's better.
However @yarda requested per cpus option. My understanding is that, this is more friendly for users using CPU-partitioning profiles , as they could then easier match cpus on which partitioning setting are used.
Anyway I'm ok with both implementations, but would like to know which is preferable, @yarda could you please provide feedback here?
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.
If the new plugin i.e. plugin_intel_uncore.py would be created ,
it could have config/device specification in configs files like this:
[intel_uncore]
max_freq_khz_delta=200000
[intel_io_uncores]
type=intel_uncore
devices=uncore*
max_freq_khz = 4000000
[intel_package_2]
type=intel_uncore
devices=package_02_die_00
max_freq_khz_procentage=95
The device names would correspond to entries in /sys/devices/system/cpu/intel_uncore_frequency/
The frequency specification could be any: percentage, direct value or delta.
Would that be ok? Feedback appreciated.
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.
I'm OK with doing this in the existing cpu plugin - but with a single value for all CPUs (i.e. don't set "per_device=True"). Would that work?
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.
I think yes, that is basically how it was done is original PR #519 - we have one global settings and apply it to all uncore's .
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.
Thanks for the info. Then it probably doesn't make sense to add this functionality to the CPU plugin which works over CPUs and we probably need the uncore TuneD plugin that will work over devices which has uncore control.
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.
Ok, thanks for feedback. Going to work on the plugin ... should be relatively easy to implement .
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.
I think this could be nice addition for profiles witch will use uncore plugin and also do cpu partitioning. I'll try to implement this as well.
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.
@yarda - you said "The cpu plugin has 'per CPU' granularity. So the uncore_max_freq_khz needs to be settable per CPU, otherwise we could break things / TuneD logic. If it's unacceptable we will probably need new plugin with the package/die granularity."
But what does the "per_device" option do when creating the command?
@command_set("uncore_max_freq_khz", per_device=True)
Doesn't setting "per_device=False" allow a command to be defined that cannot be settable per CPU? Or is it for some other purpose?
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.
per_device=False
(non-device commands) are mostly used for non-device plugins (e.g.bootloader
). For device based plugins it can be used for setting some property of the plugin instance (for example delay, path prefix, units, ...) to modify device commands behavior of the instance. It shouldn't interfere with other instances of the plugin. It also doesn't support hotplug, because hotplug is device based thing, not instance based.In case of uncore implementation as individual plugin you could for example in the TuneD profile define uncore plugin instance for high performance and uncore plugin instance for powersave (similarly as we now do with the CPUs) and later move dynamically packages/dies between the instances as needed through the runtime API. This wouldn't work if implemented in the cpu plugin with the non-device command. You could also use the built-in regex matcher to match the packages/dies via regular expressions in the TuneD profile, i.e. you could work with them in TuneD as with other devices.