coredirector - Intel TD/HFI driver - Part1: Add ITD/HFI related MSR/CPUID defines to specialregs.h

[koinec_yahoo.co.jp]

Summary

I developed the Intel Thread Director (ITD) / Hardware Feedback Interfce (HFI) device driver to obtain performance/efficiency information for each CPU core, which was implemented to improve the performance of Intel hybrid architecture CPUs. (e.g. Raptor Lake (refresh), Alder Lake, LakeField processors)

This driver simply obtains performance/efficiency information from the CPU and stores it in the "cpu_group" struct data referenced by the ULE scheduler.
However, since the ULE scheduler side is not yet supported, performance/efficiency cannot be improved by installing this driver at this time.

I will try to modify the ULE scheduler side in the future, but I posted this driver first because it can be implemented independently of this driver and it is difficult to modify the ULE scheduler.

There are seven patches, and this is the first.
This patch first adds constant definitions for CPUID and MSR to specialregs.h.

Test Plan

With the remaining patches to be submitted later, I ran the tests listed below.

• FreeBSD 15-current: Be able to apply patches and build to the latest source tree as of 2024/03/20.
• FreeBSD 14.0-Release: The source tree can be patched and built. After building, it is possible to load the driver and correctly obtain performance values from the CPU.

Due to my development environment, I developed it on FreeBSD 14.0-RELEASE and ported it to FreeBSD 15-current on a virtual environment.
However, I have also confirmed that the parts related to the code modified this time have hardly changed between 14.0-RELEASE and 15-current.
For this reason, I believe that it will probably work with 15-current, but if you are able to test it, please help confirm that it works.

[emaste]

FYI, if you have reason to upload new patches please include full context (via e.g. git show -U999999) - see https://wiki.freebsd.org/Phabricator for details.

Also, if you have a public git repo (on GitHub or elsewhere) with this work please share the link - it makes it convenient to cherry-pick changes.

[karels]

fwiw, I've been experimenting with sched_ule changes for hybrid cores, although I have nothing worth committing yet. I'll be interested to see the rest of this.

sys/x86/include/specialreg.h

352

Does this relate to the existing CPUID_HYBRID_{SMALL,LARGE}_CORE definitions, which are currently in use? Is the same information in two places?

[kib]

Please upload the patch with the full context (diff -U999999999)

sys/x86/include/specialreg.h

352

Most likely not.

[koinec_yahoo.co.jp]

This comment was removed by koinec_yahoo.co.jp.

[koinec_yahoo.co.jp]

I'm sorry.
I tried uploading a full-context patch file from "Update Diff" in the upper right menu, but when I download it afterwards, only the modified parts are shown.
Since I don't know how to use this site, I will attach the full context file here.
If I'm wrong, please let me know how to upload it.

{F79832604}

[koinec_yahoo.co.jp]

Also, if you have a public git repo (on GitHub or elsewhere) with this work please share the link - it makes it convenient to cherry-pick changes.

I'm sorry too.
Currently, I do not have a git repo where I can publish the FreeBSD source tree.
Also, it is difficult to prepare it immediately.

[koinec_yahoo.co.jp]

sys/x86/include/specialreg.h

352

CPUTPM_D_HF_{PERFORMANCE,EFFICIENCY} is a bit that determines whether the scores of Performance or Power Efficiency can be answered with Intel ThreadDirector/Hardware Feedback Interface, and is used to determine the result of CPUID LEAF 6.

CPUID_HYBRID_{SMALL,LARGE}_CORE is CPUID LEAF 1A, and when I checked the Intel SDM - 1.4 DETECTION OF FUTURE INSTRUCTIONS AND FEATURES, I understand that it is a bit to determine whether the core that executed CPUID is a so-called P core or an E core.

Therefore, these are different things.

[karels]

In D44453#1014665, @koinec_yahoo.co.jp wrote:

I'm sorry.
I tried uploading a full-context patch file from "Update Diff" in the upper right menu, but when I download it afterwards, only the modified parts are shown.
Since I don't know how to use this site, I will attach the full context file here.
If I'm wrong, please let me know how to upload it.

{F79832604}

Looks like you did it correctly. By default, Phabricator shows the diffs with limited context, but if the whole context is in the diff, you can click to show more. See the lines delimiting the sections like "Show 20 lines".

[kib]

sys/x86/include/specialreg.h

348

Naming should be put into alignment with existing symbols' names.

[koinec_yahoo.co.jp]

sys/x86/include/specialreg.h

348

Fixed naming.
Last time, I named it according to the Ebx style, but I didn't know which name followed the correct rules.

[koinec_yahoo.co.jp]

Upload a full-context patch that corrects the name of the CPUID Leaf6 constant.

part1_add_specialregs_defines_fbsd15c.patch45 KBDownload

[kib]

Please mail me (kib@f.o) the updated patch in the format of git-format-patch, with the correct metadata. Most important, put your author's email and name as you want them to appear in the git commit log.

sys/x86/include/specialreg.h

348

Let me be explicit. Names should be in style of CPUID_PERF_TD_CLASSES etc.

860

Can the name be shortened, e.g. to IA32_HW_FEEDBACK_CONF_EN_HWFEEDBACK?
Same for the next symbol.

[karels]

Is this project derived from Intel's code (see https://github.com/intel/intel_hfi)? It was originally GPL, but is now dual-licensed.

[koinec_yahoo.co.jp]

In D44453#1016452, @kib wrote:

Please mail me (kib@f.o) the updated patch in the format of git-format-patch, with the correct metadata. Most important, put your author's email and name as you want them to appear in the git commit log.

Thank you for teaching me so much.
I will send you an email after making the corrections.
Due to my current situation, it will take several weeks to fix this, but please forgive me.

[koinec_yahoo.co.jp]

In D44453#1017213, @karels wrote:

Is this project derived from Intel's code (see https://github.com/intel/intel_hfi)? It was originally GPL, but is now dual-licensed.

I understand that this github code has no origin.
I based this driver on FreeBSD's coretemp driver.

Since this is a serious topic related to licensing, I will explain it in a little more detail.
This github is the source code of the driver for Linux kernel, and I learned it.
However, the PowerManagement-related mechanisms are different between the Linux kernel and FreeBSD. In the Linux kernel, this is added to the existing thermal throtlling code, but FreeBSD does not have this mechanism.
Therefore, it is not possible to create the coredirector driver using the source code from this github.
As proof of this, for example, I needed to add the Local APIC's thermal interupt handler as a patch in Part 2.
Also, the table reference processing of Intel HFI/TD is simple, just referencing the table when an thermal interrupt occurs. I believe that if it were created based on the Intel SDM article, the process flow would be similar.

[karels]

In D44453#1018221, @koinec_yahoo.co.jp wrote:

In D44453#1017213, @karels wrote:

Is this project derived from Intel's code (see https://github.com/intel/intel_hfi)? It was originally GPL, but is now dual-licensed.

I understand that this github code has no origin.
I based this driver on FreeBSD's coretemp driver.

Since this is a serious topic related to licensing, I will explain it in a little more detail.
This github is the source code of the driver for Linux kernel, and I learned it.
However, the PowerManagement-related mechanisms are different between the Linux kernel and FreeBSD. In the Linux kernel, this is added to the existing thermal throtlling code, but FreeBSD does not have this mechanism.
Therefore, it is not possible to create the coredirector driver using the source code from this github.
As proof of this, for example, I needed to add the Local APIC's thermal interupt handler as a patch in Part 2.
Also, the table reference processing of Intel HFI/TD is simple, just referencing the table when an thermal interrupt occurs. I believe that if it were created based on the Intel SDM article, the process flow would be similar.

Thanks for the information.