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.

In D56512#1294510, @mhorne wrote:

Based on the original submission it is not a typo (D48877). It took one year for the merge to happen. I suggest just to leave it as is.

Based on the original submission it is not a typo (D48877). It took one year for the merge to happen. I suggest just to leave it as is.

LGTM

Thanks for doing this, and sorry again for the backtracking.

Use recommended wording for non-standard options.

In D56090#1289449, @ziaee wrote:

Sorry to backtrack here (and to let this slip for a while), but I did a deeper dive in preparation for merging this. Looking at our utilities that are specified in POSIX.1-2024:

xargs:
options are non-standard FreeBSD extensions which may not be available on other operating systems.

ls:
are non-standard extensions.

what:
The -q option is a non-standard FreeBSD extension which may not be available on other operating systems.

cut:
The -w flag is an extension to the specification.

pax:
operations are extensions to the POSIX standard.

date:
With the exception of the -u option, all options are extensions to the standard.

patch:
The flags [-BCEFfstVvxz] and [--posix] are extensions to that specification.

env:
options are non-standard extensions supported by FreeBSD, but which may not be available on other operating systems.

find:
are extensions to IEEE Std 1003.1-2001 (“POSIX.1”).

Looking at GNU coreutils (which doesn't provide STANDARDS or COMPATIBILITY sections), they also have both long-options and -v.

The extended documentation for the mdoc language suggests we use are extensions to that specification..

https://mandoc.bsd.lv/mdoc/style/standards.html

Sorry to backtrack here (and to let this slip for a while), but I did a deeper dive in preparation for merging this. Looking at our utilities that are specified in POSIX.1-2024:

xargs:
options are non-standard FreeBSD extensions which may not be available on other operating systems.

In D44455#1287237, @koinec_yahoo.co.jp wrote:

Regarding the modification to save the acquired score values ​​from struct cpu_group to pcpu, I'd like to use the HMP (https://reviews.freebsd.org/D54674) API rather than creating a new, intelhfi's specific variable in pcpu for saving the values.
Are there any problems with this approach? If so, please let me know.

Thank you all for your comments.