Page MenuHomeFreeBSD

intelhfi - Intel TD/HFI driver - Part4: Add intelhfi driver's source-code & Makefile.
Needs ReviewPublic

Authored by koinec_yahoo.co.jp on Mar 21 2024, 12:33 PM.
Referenced Files
F146359928: D44456.id172955.diff
Mon, Mar 2, 1:48 AM
Unknown Object (File)
Sun, Mar 1, 10:45 AM
Unknown Object (File)
Sat, Feb 21, 11:58 AM
Unknown Object (File)
Thu, Feb 19, 3:43 PM
Unknown Object (File)
Tue, Feb 17, 11:04 AM
Unknown Object (File)
Tue, Feb 17, 9:32 AM
Unknown Object (File)
Tue, Feb 17, 9:32 AM
Unknown Object (File)
Mon, Feb 16, 8:20 PM

Details

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 Part 4.
This patch is the source code and Makefile of the intelhfi driver that I developed this time.

This patch depends on the following patches:

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.

Diff Detail

Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

koinec_yahoo.co.jp created this revision.

Attach the full context patch file.
{F79836034}

Fix CPUID Leaf6 define strings.

Attach the patch file created with the git format-patch command.

minsoochoo0122_proton.me added inline comments.
sys/dev/coredirector/coredirector.c
61

device_printf(9)

66

What stops from using __builtin_popcount()?

74

Could be bitwise: (n + 7) & (~7)

163

M_COREDIR matches the name.

352

Support for LP-E?

sys/dev/coredirector/coredirector.c
352

I searched the internet for LP-E, and it looks like CPUID_HF_EFFICIENCY is applied for both E and LP-E cores. Linux has cache info in their topology, but since FreeBSD seems to lack this, we need to manually query cpuid leaf 4.

There is also reference HFI source code from Intel available at https://github.com/intel/intel_hfi

koinec_yahoo.co.jp retitled this revision from coredirector - Intel TD/HFI driver - Part4: Add coredirector driver's source-code & Makefile. to intelhfi - Intel TD/HFI driver - Part4: Add coredirector driver's source-code & Makefile..
koinec_yahoo.co.jp edited the summary of this revision. (Show Details)
  • Fix the driver name (coredirector -> intelhfi)
  • Fix review findings. (__builtin_popcount, device_printf, etc)
koinec_yahoo.co.jp retitled this revision from intelhfi - Intel TD/HFI driver - Part4: Add coredirector driver's source-code & Makefile. to intelhfi - Intel TD/HFI driver - Part4: Add intelhfi driver's source-code & Makefile..Wed, Feb 4, 12:54 PM
sys/dev/coredirector/coredirector.c
352

As far as I know, it also supports LP-E cores.

I understand that the Intel Hardware Feedback Interface is not a table with performance index value for each Performance core/Efficiency core/Low-Power Efficiency core, but rather a table with two values ​​for each core group: a performance index value (how fast it can calculate) and a power saving index value (how power efficient it is).

For this reason, I understand that LP-E cores simply have a smaller performance index value and a larger power saving index value than other cores.

However, when I created this driver, I did not have a CPU with an LP-E core, so I have not been able to confirm this. I will take some time to look into it.

sys/conf/files.amd64
126–128

alphabetical order

sys/modules/Makefile
86–88

alphabetical order

769–771

alphabetical order

This revision now requires changes to proceed.Wed, Feb 4, 7:39 PM
  • Correct the driver name insertion line to be in alphabetical order (My mistake. Sorry)

I checked the latest version of the Intel Software Developer's manual (SDM) again, and it appears that the Intel Hardware Feedback Interface / Thread Director does not provide a table with performance index values ​​for each P core/E core/LP-E core, but rather a table with two values ​​for each core group: a performance index value (computation speed) and a power saving index value (power efficiency).
It does not appear that the table or columns have been expanded for LP-E cores.

I'm also able to obtain values ​​for LP-E cores on my Core Ultra 7 155H.

koinec@claw> dmesg | grep 'CPU:' | uniq
CPU: Intel(R) Core(TM) Ultra 7 155H (2995.20-MHz K8-class CPU)

koinec@claw> sysctl dev.intelhfi.0.hwtable
dev.intelhfi.0.hwtable: 
[Dump HFI/ITD table]  TimeStamp=43dcc8f05
           Class 0    Class 1    Class 2    Class 3  
---------  Perf: Eff  Perf: Eff  Perf: Eff  Perf: Eff
  Grp  0:   67 :  36  105 :  48  168 :  56   43 :  23  (Core #0 - #1)
  Grp  1:   67 :  36  105 :  48  168 :  56   43 :  23  (Core #2 - #3)
  Grp  2:   67 :  36  105 :  48  168 :  56   43 :  23  (Core #4 - #5)
  Grp  3:   67 :  36  105 :  48  168 :  56   43 :  23  (Core #6 - #7)
  Grp  4:   63 :  38   98 :  50  157 :  59   40 :  24  (Core #8 - #9)
  Grp  5:   63 :  38   98 :  50  157 :  59   40 :  24  (Core #10 - #13)
  Grp  6:   63 :  36   98 :  48  157 :  56   40 :  23  (Core #14 - #17)
  Grp  7:   63 :  36   98 :  48  157 :  56   40 :  23  (Core #18 - #19)
  Grp  8:   63 :  38   98 :  50  157 :  59   40 :  24  (Core #20 - #21)

In the example above, checking kern.sched.topology_spec shows that cores #8-#9 are LP-E cores, and #10-17 are E cores.
However, perhaps because this H/W model is a handheld gaming PC and has strict thermal processing restrictions, there does not seem to be a significant difference between the values ​​of the E cores and LP-E cores.

sys/dev/coredirector/coredirector.c
352

It is my understanding that the current implementation supports LP-E cores.
For this reason, I don't think it's necessary to identify LP-E cores with CPUID.
Since listing the confirmation details in line comments would make them a bit long, I've included them as comments for the entire review.

The diff is off. Could you rebase main and create diff with git format-patch -U999999 --stdout main > change.diff?

You can squash all your previous and this one into one commit. (and that's preferred)

This revision now requires changes to proceed.Wed, Feb 11, 2:24 PM
  • Squash the previous review fixes and re-create the patch commit.
  • Correct the driver name insertion line to be in alphabetical order

Last time, I rebased the source tree onto the latest version just before submitting the patch, and then created the patch using the git format-patch -U999999 command.
However, in order to be able to track the change in driver name from coredirector to intelhfi, I only output the differences from the state when it was first submitted as coredirector to the patch file.
From what you taught me this time, I understood that it would be better to squash the review corrections and make it an additional patch for intelhfi as a whole, so I made that correction.
Please let me know if my understanding is incorrect.

Please remove all SCHED_ULE ifs. Recently we made a change so that scheduler can be chosen on boot time, so it's now meaningless to have SCHED_ULE or SCHED_4BSD

sys/conf/files.amd64
128

I think we had something here before? But since this is compiled as a module, we might not need anything here.

sys/modules/Makefile
771

you are missing intelfi entry here

This revision now requires changes to proceed.Sun, Feb 15, 5:36 PM
sys/conf/files.amd64
213

Ignore what I said. I couldn't see it due to phabricator glitch.

Still I'm not sure if we need to add this line when intelhfi is built as module. Can you remove this line and test?

sys/modules/Makefile
771

Ignore what I said. I couldn't see it due to phabricator glitch.

sys/conf/files.amd64
213

Even with this line deleted, I can run the make command in the /usr/src/sys/modules/intelhfi directory and build correctly.
However, if delete this line and then add "device intelhfi" line to the kernel config file under /usr/src/sys/amd64/conf and build the kernel, a build error will occur because this option cannot be used.

For this reason, I understand that this line should not be deleted.

sys/dev/intelhfi/intelhfi.c
9 ↗(On Diff #171907)

Please remove all SCHED_ULE ifs. Recently we made a change so that scheduler can be chosen on boot time, so it's now meaningless to have SCHED_ULE or SCHED_4BSD

  • Fix missing deletion of conditional decision by SCHED_ULE constant. (Sorry, that was my mistake)

Can we enable/disable the whole module when one or both of HMP and SMP aren't enabled? I don't see why we need to build this driver when HMP and SMP don't exist.

sys/dev/intelhfi/intelhfi.c
9 ↗(On Diff #172955)

With SCHED_ULE, do we need to include opt_sched.h? I'm not sure, probably SMP needs it.