Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Marvell has requested we add a new tuned profile for their ThunderX2-based and upcoming platforms. Tuning suggestions so far are:
- Disable transparent hugepages by default
- Disable kernel numa_balancing by default
- Adjust kernel.sched_latency_ns and kernel.sched_migration_cost_ns based on benchmark results
Comment 1Jaroslav Škarvada
2019-08-30 09:59:21 UTC
Comments from the bug 1746957 are also valid here.
Comment 2Jaroslav Škarvada
2020-05-07 21:01:20 UTC
According to the previous communication we will probably not add new profile, but we will incorporate the tuning into the existing throughput-performance profile. It will result in better user experience - i.e. user will select throughput-performance profile and arch specific tuning will be automatically applied depending on the architecture Tuned is running on.
Comment 3Jaroslav Škarvada
2020-05-07 21:06:56 UTC
Can we apply it on all ARM machines which cpuinfo string contains ThunderX? Or on all ARM machines? If not, could you provide list of cpuinfo strings this should be applied on?
Comment 4Jaroslav Škarvada
2020-05-27 19:12:31 UTC
Also we still don't know values for the kernel.sched_latency_ns and kernel.sched_migration_cost_ns.
Comment 5Jaroslav Škarvada
2020-06-03 17:35:17 UTC
For now I am using the following 'CPU part' numbers:
0x516, thunderx2t99
0x0516, thunderx2t99
0xaf, thunderx2t99
0x0af, thunderx2t99
0xa1, thunderxt88
0x0a1, thunderxt88
Please let me know if you know more.
Also due to the [1] it's possible to force the tuning even on platforms that have new CPU part numbers which are currently unknown to Tuned, e.g. by adding the following to the /etc/tuned/tuned-main.conf:
uname_string = aarch64
cpuinfo_string = CPU part : 0x0af
[1] https://github.com/redhat-performance/tuned/pull/270
Comment 6Jaroslav Škarvada
2020-06-03 19:30:42 UTC
Comment 7Jaroslav Škarvada
2020-06-03 19:37:27 UTC
(In reply to Jaroslav Škarvada from comment #6)
> According to the previous communication we targeted all AMDs. PR for what we
> currently have:
> https://github.com/redhat-performance/tuned/pull/276/commits/
> 89083a8459e71789c9791aa98eeb74c0cd34105c
Of course it's targeting the ARM CPUs from the comment 5, not the AMD :) It's one PR with two commits adding support for both ARM and AMD and I have just copied the wrong description here :)
(In reply to Jaroslav Škarvada from comment #5)
> For now I am using the following 'CPU part' numbers:
>
> 0x516, thunderx2t99
> 0x0516, thunderx2t99
> 0xaf, thunderx2t99
> 0x0af, thunderx2t99
> 0xa1, thunderxt88
> 0x0a1, thunderxt88
May I ask where you got these numbers?
Comment 10Jaroslav Škarvada
2020-06-04 14:41:52 UTC
(In reply to Ondřej Lysoněk from comment #9)
> (In reply to Jaroslav Škarvada from comment #5)
> > For now I am using the following 'CPU part' numbers:
> >
> > 0x516, thunderx2t99
> > 0x0516, thunderx2t99
> > 0xaf, thunderx2t99
> > 0x0af, thunderx2t99
> > 0xa1, thunderxt88
> > 0x0a1, thunderxt88
>
> May I ask where you got these numbers?
GCC sources. I checked it with the subset of machines I was able to found in Beaker and it matched.
It seems in gcc-10.1.1 there are even more IDs:
0xa0, 0x0a2, 0x0a3, 0x0b8
I will add them.
I was also asking whether we could match the "CPU implementer" with the 0x43, but I didn't get answer to it. It also seems the 0x42 is used. Both seems to be used by Broadcom - maybe it's too rough identification.
Pinging Chris Tatman, our Marvell EPM. Chris, can we get this in front of Marvell to make sure this is how they'd like to have the CPUs identified? I believe we can add or alter the list when Altra is supported but I'd like to get their input as we discussed before and during the TRF last week.
Comment 12Jaroslav Škarvada
2020-06-05 08:36:56 UTC
I used the following regex:
'CPU part\s+:\s+(0x0?516)|(0x0?af)|(0x0?a[0-3])|(0x0?b8)\b'
We can alter it any time by Tuned update. Admin can also override it with help of https://github.com/redhat-performance/tuned/pull/270.
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 (tuned bug fix and enhancement update), 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:4559