RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1748965 - RFE: specific tuning according to /proc/cpuinfo
Summary: RFE: specific tuning according to /proc/cpuinfo
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: tuned
Version: 8.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.0
Assignee: Jaroslav Škarvada
QA Contact: Robin Hack
URL:
Whiteboard:
Depends On:
Blocks: 1743192 1755139
TreeView+ depends on / blocked
 
Reported: 2019-09-04 14:54 UTC by Jaroslav Škarvada
Modified: 2023-05-17 12:03 UTC (History)
8 users (show)

Fixed In Version: tuned-2.13.0-0.1.rc1.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:59:29 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-27296 0 None None None 2023-05-17 12:03:19 UTC
Red Hat Product Errata RHBA-2020:1883 0 None None None 2020-04-28 17:00:12 UTC

Description Jaroslav Škarvada 2019-09-04 14:54:41 UTC
Description of problem:
Tuned needs a mechanism to conditionally tune systems according to CPU and its capabilities.

The proposal is to conditionally apply blocks from the Tuned profile according to the /proc/cpuinfo matches.

Version-Release number of selected component (if applicable):
tuned-2.12.0-3.el8

How reproducible:
Always

Steps to Reproduce:
1. Try to tune system conditionally according to the CPU used
2.
3.

Actual results:
There is no user friendly and easy way how to do it (not counting complex workarounds with the conditional include).

Expected results:
User friendly mechanism for conditional tuning according to the CPU used and its capabilities.

Additional info:

Comment 1 Jaroslav Škarvada 2019-09-04 14:57:41 UTC
This could be handled more generic way to allow future extensions - e.g. to support matching similar what the 'recommend.conf' allows.

Comment 5 Jaroslav Škarvada 2019-11-21 09:46:34 UTC
Current proposal is to extend plugin instances matching of uname_regex and cpuinfo_regex, e.g.:

[variables]
cannonalake_cpuinfo=.*\bREGEX1\b.*
cannonlake_uname=REGEX2

[cpu_cannonlake]
type=cpu
cpuinfo_regex=${cannonlake_cpuinfo}
uname_regex=${cannonlake_uname}
force_latency=C1

[diks_cannonlake]
type=disk
cpuinfo_regex=${cannonlake_cpuinfo}
uname_regex=${cannonlake_uname}
readahead=4092

...

And also addition of operator for conditional includes of subprofiles for specific HW, e.g.:

[main]
include=${cpu:${cannonlake_cpuinfo}:file_cannonlake.conf:other.conf}

[variables]
cannonalake_cpuinfo=.*\bREGEX1\b.*

Comment 6 Jaroslav Škarvada 2019-11-22 11:14:45 UTC
(In reply to Jaroslav Škarvada from comment #5)
> And also addition of operator for conditional includes of subprofiles for
> specific HW, e.g.:
> 
> [main]
> include=${cpu:${cannonlake_cpuinfo}:file_cannonlake.conf:other.conf}
> 
> [variables]
> cannonalake_cpuinfo=.*\bREGEX1\b.*

Current proposal for the second feature (fallback_profile will be used when nothing matches, it's optional):

[main]
include=${cpuinfo:${cannonlake_cpuinfo_regex}:cannonlake_tuned_profile:$(cascadelake_cpuinfo_regex}:cascadelake_tuned_profile:...:fallback_profile}

[variables]
cannonalake_cpuinfo_regex=.*\bREGEX_CANNONLAKE\b.*
cascadelake_cpuinfo_regex=.*\bREGEX_CASCADELAKE\b.*
...

It's also possible to combine it with the base profile, the following loads base_tuned_profile and adds specific CPU profile on top of it:

[main]
include=base_tuned_profile,${cpuinfo:${cannonlake_cpuinfo_regex}:cannonlake_tuned_profile:$(cascadelake_cpuinfo_regex}:cascadelake_tuned_profile}

Comment 7 Jaroslav Škarvada 2019-11-22 14:28:30 UTC
Upstream PR:
https://github.com/redhat-performance/tuned/pull/218

It's possible to write now:

[variables]
cannonalake_cpuinfo=.\bGenuineIntel\b.
cannonlake_uname=x86_64

[cpu_cannonlake]
type=cpu
cpuinfo_regex=${cannonlake_cpuinfo}
uname_regex=${cannonlake_uname}
force_latency=C1

[disk_cannonlake]
type=disk
cpuinfo_regex=${cannonlake_cpuinfo}
uname_regex=${cannonlake_uname}
readahead=4092

...

And the tuning will be applied only on machines which have
'GenuineIntel' string in the /proc/cpuinfo and x86_64 architecture (from
uname). Both 'cpuinfo_regex' and 'uname_regex' are optional - if not
used it has the same effect as if matching regex is used. This example
used variables but it also works without it.

Also cpuinfo_check builtin function was added, so it's possible to write
the following now:

[main]
include=${f:cpuinfo_check:\bGenuineIntel\b:intel_profile:other_profile}

It tries to match the regex '\bGenuineIntel\b' in the /proc/cpuinfo
and if it matches it includes 'intel_profile', if not it includes
'other_profile'. If colon ':' needs to be used in the regex, it needs
to be escaped, i.e.: ':'

It's even possible to combine it with the generic profiles, e.g.:
[main]
include=base_profile${f:cpuinfo_check:\bGenuineIntel\b:,intel_profile}

It will always include 'base_profile' and if the cpuinfo matches
GenuineIntel it also adds the intel_profile. More variants are possible,
the generic syntax is:

${f:cpuinfo_check:REGEX1:STR1:REGEX2:STR2,...[,FALLBACK_STR]}

It returns STR1 if REGEX1 matches, STR2 if REGEX2 matches, and
FALLBACK_STR if nothing matches. If there is no FALLBACK_STR it returns
empty string on no match. It exits on the first match found and
no more regexes are processed in such case

TODO:
Current limitation: Variables are not expanded in the include, so it's
not possible to write:

[main]
include=${f:cpuinfo_check:${regex}:test}

[variables]
regex=TEST

Comment 8 Jaroslav Škarvada 2019-11-25 12:12:02 UTC
(In reply to Jaroslav Škarvada from comment #7)
> It will always include 'base_profile' and if the cpuinfo matches
> GenuineIntel it also adds the intel_profile. More variants are possible,
> the generic syntax is:
> 
> ${f:cpuinfo_check:REGEX1:STR1:REGEX2:STR2,...[,FALLBACK_STR]}
> 
Typo, it should be:
${f:cpuinfo_check:REGEX1:STR1:REGEX2:STR2:...[:FALLBACK_STR]}

Comment 9 Jaroslav Škarvada 2019-11-26 20:13:14 UTC
Just to be clear the example in comment 7 is just synthetic to demonstrate the feature and it will not match Cannonlake CPUs. It matches any x86_64 Intel CPU. For Cannonlake matching correct CPU/model regexes needs to be supplied instead of the generic regex used.

Comment 16 errata-xmlrpc 2020-04-28 16:59:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1883


Note You need to log in before you can comment on or make changes to this bug.