In D44456#1310982, @koinec_yahoo.co.jp wrote:

However, intelhfi driver needs to reference the number of CPU groups stored in the "cpu_group" structure. For this reason, I used the "cpu_grpup" structure in the location you pointed out, and also cached it in the intelhfi's instance structure.

@koinec_yahoo.co.jp Are you fine if I update the diff to match FreeBSD's man style? The content is fine, I just need to rephrase and move sections around for consistency with other man pages. You will still be the only person on the copyright notice and git author.

Wait, could you add this to amd64/LINT as well?

LGTM

• Fix the copyright year notation in the file comments (Sorry).
• Fix a bug where the number of CPU groups in the cpu_group structure was unnecessarily cached within the instance.

Fix an error where a line defining HMP options was mistakenly left in when adding support for HMP(4) (Sorry).

• Fix the year of creation in the file comment.
• Fix the creation date.

Great! Then I will close this revision.

Ping.

Thanks, here are some reviews:

In D55632#1307092, @jilles wrote:

Is signal(3) the right reference? C code had better use sigaction(2) instead, or the list might be moved to a new signal(7) page?

Is signal(3) the right reference? C code had better use sigaction(2) instead, or the list might be moved to a new signal(7) page?

• Modify the core with the highest performance to register its capacity value as 1024.
• Modify the priority of registering capacity and score providers in HMP(4) to 40.

• Fix and improvement related to HMP(4) support

In D56648#1303087, @ziaee wrote:

In D56648#1303053, @tembun_bk.ru wrote:

Can we have it in 15.1? I guess it would be reasonable, since we already have groups(7) there. They look better together.

I actually did not merge groups.7 into 15.1. This was my mistake. Let me see if I can address that.

In D44456#1304562, @koinec_yahoo.co.jp wrote:

As you pointed out, the P-cores are #0-7 and #18-21, but the value for #18-21 is higher. Upon investigation, this appears to be due to it being a "Favored Core."
While I haven't yet confirmed this description in Intel SDM, my web research suggests that Intel designates cores with particularly superior semiconductor performance as "Favored Cores" in its CPUs.
To prioritize the use of these cores over other P-cores, a slightly higher capacity is set, as shown in the log above.

• All cores have similar perf/eff scores, which is good because it means all cores are doing similar work. Just want to verify that this is a expected result.

Thank you very much for checking it.
I'm glad to hear that there wasn't a major misunderstanding regarding the use of HMP(4).

I have two questions from the log file:

• All cores have similar perf/eff scores, which is good because it means all cores are doing similar work. Just want to verify that this is a expected result.
• Capacities should be scaled to 1024, the max one being 1024. But another issue see is that although this cpu has 6 P cores, 8 E cores, and 2 LP-E cores (22 threads in total), the capacity output doesn't match that classification.

I suggest keeping intelhfi sysctls even though we have hmp for the following reasons:

• Someone might want to debug hardware by reading values directly from the driver.
• Some people might not want to have HMP enabled in their kernel (e.g. they think hybrid scheduling is premature) but still want to observe values reported by intelhfi.

<Additional Information: Other Notes>

After much consideration, the capacity of hmp(4) now stores the High Performance score value obtained from Intel HWP.

I've modified intelhfi(4) to store the score value in hmp(4) (https://reviews.freebsd.org/D56547), which was created by Minsoo.
I apologize for the delay; please review it.

Since the acquired score is stored in DPCPU using HMP(4), this Part 3 patch is no longer necessary. Therefore, please withdraw it.

In D56648#1303053, @tembun_bk.ru wrote:

Can we have it in 15.1? I guess it would be reasonable, since we already have groups(7) there. They look better together.

Can we have it in 15.1? I guess it would be reasonable, since we already have groups(7) there. They look better together.

I recommend you to read the latest fexecve(2) man page, where it discusses /dev/fd in relation to the scripts.

Address @kib's comments:

Reference users.7 in intro.7.

Stopped there, will wait for all comments processed.

In D56661#1297878, @jilles wrote:

The #! mechanism is already described (more briefly) in lib/libsys/execve.2 lines 73...100. That duplication is certainly undesirable.

I don't really have an opinion whether the text in lib/libsys/execve.2 needs to be extended or moved to a new page share/man/man7/script.7.

The #! mechanism is already described (more briefly) in lib/libsys/execve.2 lines 73...100. That duplication is certainly undesirable.

Forgot to include users.7 in MAN variable in Makefile.