Page MenuHomeFreeBSD
Files F160968638

IntegrationStrategy_for_hmp_sched_ule_And_PerformanceImprovementReport.txt
koinec_yahoo.co.jp (Koine Yuusuke)
Actions

Authored By
koinec_yahoo.co.jp
Mon, Jun 29, 12:15 PM
Size
37 KB
Referenced Files
None
Subscribers
None

IntegrationStrategy_for_hmp_sched_ule_And_PerformanceImprovementReport.txt
View Options

This document is not UTF8. It was detected as EUC-JP and converted to UTF8 for display.
## Integration Strategy for hmp(4) & sched_ule(4) / Performance Improvement Report for intelhfi(4) Usage ##################
* Author: Koine Yuusuke
* Date: 2026/06/28 JST
<<Overview of this report>>------------------------------------------------------------------------------------------------
* I modify sched_ule(4) to utilize hmp(4), enabling CPU core selection based on performance considerations.
* I conducted performance testing with intelhfi(4), hmp(4), and sched_ule(4) integrated.
* The results showed a performance improvement of 10?30% when executing processes with a thread count lower than the
number of physical P-cores.
<<Objective>>--------------------------------------------------------------------------------------------------------------
* Modify 'sched_ule(4)' to reference the 'capacity' and 'score' of hmp(4). This change aims to further enhance
the performance of the ULE scheduler by efficiently placing tasks in heterogeneous multi-core environments while
taking CPU core performance into account.
<<Overview of Modifications>>----------------------------------------------------------------------------------------------
* Task assignment to CPU cores in sched_ule(4) is performed via the following three paths, with the final CPU core
selection handled by the cpu_search_lowest() function:
1) When adding a task:
sched_ule_add() [API] -> sched_pickup() -> sched_lowest() -> cpu_search_lowest()
2) When performing inter-CPU load balancing:
sched_ule_clock() [API] -> sched_balance() -> sched_balance_group() -> sched_lowest() -> cpu_search_lowest()
3) When forcibly moving a task to another CPU:
sched_ule_sswitch() [API] -> sched_pickup() -> sched_lowest() -> cpu_search_lowest()
* The cpu_search_lowest() function traverses the smp(4) CPU topology based on CPU core groups, calculating "load scores"
first for individual CPU cores and then for CPU core groups. It selects the CPU core group with the lowest load score,
and subsequently selects the CPU core with the lowest load score within that group.
* Paths 1) and 3) utilize the sched_pickcpu() function. sched_pickcpu() selects the optimal CPU by calling
cpu_search_lowest() multiple times via the sched_lowest() wrapper function, progressively relaxing search criteria
that account for factors such as interrupt processing, cache validity and hierarchy, and Hyper-Threading (SMT) effects.
* OS schedulers, such as the ULE scheduler, represent the culmination of refined technology and tuning efforts that
incorporate various factors and practical experience. Therefore, I aim to respect the overall design and policy while
minimizing the scope and volume of modifications as much as possible.
* In light of these circumstances, I have modified the cpu_search_lowest() function to account for the per-CPU-core
performance recorded in hmp(4) when calculating the "load score" for each core and searching for the core with the
lowest load score.
* The load balancing process in Path 2) utilizes the cpu_search_highest() function to select the source CPU core
(the one with the highest load), in addition to using cpu_search_lowest() to select the destination core.
As detailed later, since cpu_search_highest() calculates the "load score" using the same logic as cpu_search_lowest(),
I have similarly modified it to take into account the per-CPU-core performance recorded in hmp(4).
<<Modification of the cpu_search_lowest() function>>-----------------------------------------------------------------------
* The original sched_ule(4) implements the following logic:
- It calculates a CPU core's "load score" by taking the number of tasks in its run-queue (obtained via the TDQ_LOAD()
macro) and multiplying it by a fixed adjustment factor of 256. Within the range of this factor-effectively the weight
equivalent to the load of a single task-it applies adjustments such as prioritizing specific cores or using random
distribution to prevent bias toward any single core. It then sums the "load scores" of the cores within a CPU core
group to calculate that group's total "load score."
- After calculating these scores, the system first searches for the CPU core group with the lowest "load score,"
and then searches for the specific core within that group that has the lowest "load score."
- As an exception, when comparing "load scores" between CPU core groups, a penalty is applied to the score if the group
in question is a logical CPU core group formed by SMT (Hyper-Threading) - hereafter referred to as an "SMT group" -
and it contains active tasks. This measure addresses the inherent characteristics of SMT groups: because execution
units (such as ALUs) are shared between logical cores, placing tasks on both logical cores simultaneously results
in a significant drop in computational efficiency.
* This implementation represents an excellent design for the ULE scheduler, operating efficiently when all CPU cores
have identical processing performance and all CPU core groups contain the same number of cores.
* However, with modern hybrid CPUs, these two premises often no longer hold true. Consequently, I believe the scheduler
may assign tasks indiscriminately to slower power-efficient cores and high-performance cores alike, or prioritize
Hyper-Threading cores over power-efficient core groups that actually have unused cores available.
To address this issue, I propose the following four major modifications:
a) Change the adjustment factor used in load score calculation from 256 to the `capacity` value defined in hmp(4),
which represents the theoretical performance of each CPU core.
b) Ensure that the number of CPU cores matches when comparing the total load scores of CPU core groups.
c) Adjust the penalty value applied to SMT (Hyper-Threading) CPU core groups based on the CPU core `capacity` values.
d) Implement CPU core steering logic using the `score` value from hmp(4).
e) Implement load score distribution logic using the `score` value from hmp(4).
a) Change the adjustment factor used for load score calculation from 256 to the `capacity` value defined in hmp(4),
which represents the theoretical performance of each CPU core.
- For "load score" calculation, the adjustment factor for the slowest CPU core is set to 256;
for other CPU cores, the factor is calculated by dividing 256 by the performance ratio relative to the slowest core.
For example, a core twice as fast as the slowest core would have a factor of 256/2 = 128, and a core four times
as fast would have 256/4 = 64.
- The number of tasks used to accumulate these adjustment factors is obtained via the TDQ_LOAD() macro.
This macro references the tdq_load member of `struct tdq`, and the tdq_load_add() function increments this member
when a task is added. In other words, the system evaluates load based on the number of tasks rather than the
specific load of each individual task.
- This behavior assumes that the load imposed by each task is constant. Consequently, if one task is assigned to the
slowest core (adjustment factor 256) and two tasks are assigned to a core twice as fast (adjustment factor 128),
the load score in both cases is 256, meaning they are theoretically evaluated as having the same load.
- The `capacity` value in hmp(4) uses a 0 - 1024 scale to ensure future precision, a convention I intend to respect.
However, I am redefining the values such that the slowest CPU is assigned a capacity of 1024, while other cores are
assigned values calculated by dividing 1024 by their performance ratio relative to the slowest core.
- When referencing the `capacity` value of hmp(4), use the return value of the accessor function hmp_get_capacity()
by right-shifting it by 2 bits and adjusting it so that the maximum value is 256.
b) Ensure that the number of CPU cores matches when comparing the total load scores of CPU core groups.
- Suppose there are two CPU core groups, A and B, and group A has more cores than group B.
In this case, perform a correction process based on the following logic to align the core counts serving as the
basis for the total load scores of both groups:
# If A divided by B results in no remainder (remainder is 0):
Multiply the total load score of CPU core group B by the value of "number of cores in group A / number of cores
in group B" to calculate the adjusted total load score for group B, then compare it with the total load score of
group A.
# If A divided by B results in a remainder (remainder is not 0):
Multiply the total load score of CPU core group A by the number of cores in group B to calculate the adjusted
total load score for group A.
Multiply the total load score of CPU core group B by the number of cores in group A to calculate the adjusted
total load score for group B.
Then, compare the adjusted total load score of group A with the adjusted total load score of group B.
Ideally, the least common multiple (LCM) of the core counts for groups A and B should be calculated;
however, calculating the LCM requires recursive processing that incurs excessive overhead.
Furthermore, since the number of CPU cores is almost always a multiple of 2, a cross-multiplication method is
used to determine a common multiple instead. In conjunction with the aforementioned correction processing for
the total load score of each CPU core group, similar correction processing is also applied to values such as the
total load scores of all CPU core groups within the CPU topology hierarchy currently being explored, the number
of CPU cores serving as a basis for the correction processing, and the total 'capacity' values of CPU core groups
used to calculate penalty values for SMT groups (which will be explained next).
　
c) Adjust the penalty value applied to SMT (Hyper-Threading) CPU core groups based on the CPU core `capacity` values.
- Fundamentally, in an SMT-group, the constituent CPU cores share execution units such as ALUs.
Consequently, while processing is fast when a task runs on only one of the CPU cores, the total processing
efficiency drops significantly when tasks run in parallel across the multiple logical CPU cores within the group.
- Particularly with Intel CPUs, while P-cores in an SMT-group have higher capacity values than E-cores, there are
cases where running all E-cores (which consist entirely of physical cores) yields higher performance than running
both cores of an SMT-group in parallel.
- Performance degradation in an SMT-group occurs only when both constituent cores are used simultaneously;
performance remains high if only one core is used.
Therefore, it is incorrect to artificially lower the capacity value of either logical core in advance.
- For this reason, the original sched_ule(4) implementation applies a penalty of 128 to the SMT-group's "load score"
if one or more tasks are already running in the group and a request is made to use a CPU core within that group.
Breaking down this load score penalty of 128 - given that an SMT-group typically consists of two logical cores -
results in a penalty of 64 per logical core. This value is one-quarter of the original adjustment factor of 256.
- Based on this, the current modification adopts a penalty value equivalent to the sum of penalties for two cores,
calculated as one-quarter of the average capacity value of the SMT-group's CPU cores (where capacity values are
adjusted via a 2-bit right shift to cap them at a maximum of 256). Regarding this penalty value, in addition to
applying the core count correction process described in (b), I also implemented propagation to higher levels to
handle cases where the CPU topology consists of three or more tiers.
d) Implement CPU core steering logic using the `score` value from hmp(4).
- Certain CPUs - such as Intel's hybrid architecture processors (12th Gen Core i series and later, Core Ultra, etc.) -
possess the capability to signal the OS regarding which CPU cores should be prioritized for use based on thermal
and load conditions. Consequently, leveraging this feature allows for more efficient utilization of CPU resources.
- The sched_ule(4) scheduler is designed with a strong emphasis on cache locality and validity, implementing logic
to minimize task migration between cache domains. While this is an excellent design, it implies that once a task
is assigned to a specific CPU core group, it will generally not be moved to another group unless conditions
- such as the assigned group becoming heavily congested relative to others - necessitate it.
- With the original sched_ule(4) or even with only the measures described in (a), (b), and (c) above, the scheduler
relies on random distribution logic to select cores - often resulting in random assignments, particularly when many
cores are idle. In scenarios where the number of active tasks is low relative to the total core count and each task
performs heavy computation, tasks should ideally be assigned to high-performance cores;
however, the current random assignment approach distributes tasks evenly, sometimes placing them on low-performance,
power-efficient cores. Furthermore, once a task is assigned, the system's preference for maintaining cache
efficiency means it is unlikely to switch to a high-performance core later.
- To address this issue, I determined that I could improve core selection by steering tasks toward the
highest-performance cores available among those currently unassigned.
- Specifically, I implemented logic to subtract the score value obtained via the hmp_get_score() accessor function
from the load score of each CPU core. Since the score value from hmp(4) operates on a 0 - 1024 scale, it is
right-shifted by 2 bits to adjust it to a 0 - 256 scale.
- The hmp(4) score value can be obtained based on either a performance metric or a power-saving metric;
however, the current implementation targets performance improvement and thus exclusively retrieves the performance
metric. In the future, I plan to implement a mechanism to switch to the power-saving metric, thereby enabling
scheduling that enhances energy efficiency.
e) Implement load score distribution logic using the `score` value from hmp(4).
- The original sched_ule(4) implements a distribution mechanism using random numbers when selecting among CPU cores
with the same task count, ensuring the selection is not biased toward any specific core.
Specifically, it subtracts from the load score the remainder obtained by dividing a random integer by 128 (half of
the adjustment factor, 256).
- Therefore, considering the intent of the aforementioned modification, the divisor should ideally be half of the
hmp(4) 'capacity' value for each CPU core. However, due to the circumstances described in point (a) above
- where slower cores are assigned the maximum capacity value - using this approach would significantly increase
the likelihood of prioritizing slower cores.
- On the other hand, when selecting a CPU core from among those with identical load scores (calculated via the
measure in point (a)), I determined it would be better to steer the selection toward the cores that the hardware
is designed to prioritize for active use.
- Consequently, I modified the logic to subtract the remainder of a random integer divided by the hmp(4) score value
from the load score. Note that since the hmp(4) score value operates on a 0 - 1024 scale, I right-shift it by
2 bits to cap the maximum value at 256.
- While the original sched_ule(4) implementation uses 128, a maximum value of 256 might appear to create an
excessively strong distribution effect. However, even after the 2-bit right shift, the hmp(4) score value maxes
out at 256; in practice, the values reported by the hardware are often much lower, and the system is not tuned so
that the highest-priority CPU necessarily has a score of 256.
For this reason, I intentionally utilize the value with a maximum of 256.
<<Modification of the cpu_search_highest() function>>----------------------------------------------------------------------
* The reasons for the modification are as follows:
- In the load balancing process for "Path 2" (as outlined in the modification summary), the cpu_search_lowest()
function is used to find the destination CPU core with the lowest load score;
however, it is also necessary to select the source CPU core. When selecting this source CPU core, the logic must
mirror that of cpu_search_lowest() but target the CPU core with the *highest* "load score".
Proper balancing cannot be achieved unless the selection criteria for both source and destination CPU cores are
aligned in this manner.
- In sched_ule(4), the cpu_search_highest() function is responsible for identifying the source CPU core;
it operates on the same fundamental logic as cpu_search_lowest() but searches for the CPU core with the "maximum
load score." Therefore, the cpu_search_highest() function modify - just like cpu_search_lowest() - to take into
account the performance characteristics of each CPU core as recorded in hmp(4).
* To address this issue, I propose the following modifications:
a') Change the adjustment factor used in load score calculation from 256 to the hmp(4) 'capacity' value,
which represents the theoretical performance of each CPU core.
b') When comparing the total load scores of CPU groups, ensure the number of CPU cores in the groups being compared
is matched.
f ) Change the random distribution range - used when multiple CPU cores are processing the maximum number of tasks -
from 256 to the hmp(4) capacity value.
a') Change the adjustment factor used in load score calculation from 256 to the hmp(4) 'capacity' value,
which represents the theoretical performance of each CPU core.
- Similar to the cpu_search_lowest() function, when calculating the load score, the adjustment factor for the slowest
CPU core is set to 256; for other CPU cores, the factor is calculated by dividing 256 by the performance ratio
relative to the slowest core.
b') When comparing the total load scores of CPU groups, ensure the number of CPU cores in the groups being compared is
matched.
- Similar to the cpu_search_lowest() function, I apply a correction to the total load scores of the CPU groups being
compared (Group A and Group B) to ensure the number of CPU cores in each group matches.
f ) Change the random distribution range - used when multiple CPU cores are processing the maximum number of tasks -
from 256 to the hmp(4) capacity value.
- The original sched_ule(4) implementation includes a feature that adjusts load scores using random numbers to
prevent bias in CPU core selection when multiple cores are processing the same number of tasks and share the
maximum load score. This feature is implemented by subtracting the remainder - obtained by dividing a random
integer by the adjustment factor (256) - from the load score. In other words, the adjustment is performed within
the range of the adjustment factor, 256. In this modification, the adjustment factor will be changed from a fixed
value of 256 to use the capacity value from hmp(4); this ensures that adjustments are made only within the range
of the capacity value.
<<Issues & ToDo>>----------------------------------------------------------------------------------------------------------
* This modification is merely an initial proposal for integrating hmp(4) and sched_ule(4); it is by no means a finished
version. Consequently, while it may take time, I believe the following improvements are necessary:
- Measures against overflow in the total load score variables (load / bload)
Load scores for CPU core groups can exceed their base values by a factor of ten or more - particularly when core
counts are not evenly divisible - in order to normalize them across groups.
There is a lingering concern that the 32-bit signed integer limit could be exceeded if the number of concurrent
tasks or installed CPU cores is extremely high. However, since I do not currently anticipate scenarios where such
a large number of tasks would simultaneously enter the run queue, this factor has been excluded from consideration
for the time being. While this issue could be resolved by simply changing the `load` and `bload` variables to
uint64_t, doing so would restrict the implementation to 64-bit CPUs. Although most heterogeneous multi-core CPUs
are currently 64-bit processors, the ARMv7 architecture can also support heterogeneous multi-core configurations;
therefore, it remains unclear whether support for this is required.
I believe this point warrants discussion during the future review process.
- Pre-calculating the common multiple of core counts when comparing total load scores between CPU core groups
Currently, the calculation of the common multiple and the subsequent adjustment logic are performed during every
core search; however, the common multiple calculation could be executed during the scheduler's initialization phase.
This would reduce the computational complexity within the cpu_search_lowest() and cpu_search_highest() functions
to simple multiplication.
- Utilization of hmp(4) power-saving metrics
The current implementation relies solely on performance metrics, prioritizing performance over power efficiency.
I believe it is necessary to enable switching to power-saving metrics. Furthermore, if power-saving metrics are to
be utilized, I must consider whether the current the avobe d) is sufficient on its own.
- CPU core allocation based on task priority
The ULE scheduler possesses excellent capabilities for distinguishing between interactive and batch tasks and
scheduling them accordingly. Consequently, I believe further improvements could be achieved by leveraging this
distinction in core allocation. However, at present, I have not yet determined which core assignments would yield
the greatest efficiency.
- Consideration of thread classes
Technologies such as Intel Thread Director and AMD HFI classify tasks into specific "classes" based on the type of
instruction processing - such as standard computational operations versus SIMD instruction execution - and provide
performance and power-efficiency metrics for each class. It is also possible to identify the class of the task
currently running on a given CPU core. Therefore, by analyzing the current task class - particularly during load
balancing - and incorporating that class's score into the overall load score calculation, more efficient task
allocation becomes possible. While I do not currently support this functionality, implementing it will be necessary
in the future.
<<Measurement Results>>----------------------------------------------------------------------------------------------------
* Tests were conducted in the following two environments, comparing the GENERIC configuration of the "current" source
tree (as of June 27, 2026) against a configuration with all patches for sched_ule(4), hmp(4), and intelhfi(4) applied.
* Measurements utilized `sysbench` version 1.0.20_2 from `ports/benchmarks`.
Tests were run with thread counts of 4, 6, 8, 10, 12, 16, and 20; for each thread count, 12 measurement runs were
performed, and the resulting scores were compared.
The tests were executed without Xorg and with no other processes running.
* The results are as follows.
<1> Intel/ASUS NUC13Pro NUC13L3Hv7 (Mini Desktop)
[CPU] Intel Core i7-1370P (6 x P-core(with HT) / 8 x E-core)
[Mem] 32 GByte
[Kernel Config] GENERIC
Use Cores 4 6 8 10 12 16 20
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Sample 1 29256908.74 45009378.55 57544228.33 66429954.69 72598573.14 88335022.30 101016954.54
Sample 2 29004174.93 45073033.01 55806659.91 66035217.48 72613608.68 88284009.64 101129322.73
Sample 3 29014634.12 41514492.71 56753299.10 64293221.77 73155059.17 87828344.58 100786432.57
Sample 4 25454653.38 41426580.75 57294550.21 65114154.29 72293135.67 88213259.57 100669095.19
Sample 5 25610348.32 45115592.93 57431382.83 65441082.10 72558048.02 88130239.25 100991741.63
Sample 6 29337019.37 41473377.80 57023890.64 65941576.57 73321088.02 88200629.97 101230488.62
Sample 7 25541935.75 45120503.27 57188107.77 63785802.91 72864688.67 87364656.14 100382588.84
Sample 8 32871574.16 41412147.93 57463357.01 63893481.49 72964044.80 88223959.73 100456204.15
Sample 9 29154791.52 41343966.17 57633022.82 66066649.10 73025041.21 88137237.53 100727021.25
Sample 10 29101960.84 45113710.89 57608319.26 63905718.46 72679925.62 88011019.94 100625312.17
Sample 11 29138889.15 41465564.90 57310631.85 64556407.79 72759425.52 88165680.49 100966358.74
Sample 12 29139955.02 45366397.55 57150994.49 64568502.35 72720408.11 88192514.87 100681164.39
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Min 25454653.38 41343966.17 55806659.91 63785802.91 72293135.67 87364656.14 100382588.84
Max 32871574.16 45366397.55 57633022.82 66429954.69 73321088.02 88335022.30 101230488.62
Avg. 28552237.11 43286228.87 57184037.02 65002647.42 72796087.22 88090547.83 100805223.74
Meian 29120425.00 43261935.63 57302591.03 64841328.32 72739916.82 88179097.68 100756726.91
Median Per Core 7280106.25 7210322.61 7162823.88 6484132.83 6061659.73 5511193.61 5037836.35
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
[Kernel Config] hmp(4) / intelhfi(4) enable + sched_ule(4) patched
Use Cores 4 6 8 10 12 16 20
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Sample 1 32786738.39 48682126.54 57300721.50 68534511.01 73210056.91 88379200.17 100905401.05
Sample 2 32702790.38 48822204.22 57250905.80 65410559.00 73917352.31 88282374.69 100950848.41
Sample 3 32878311.56 48840662.72 57470685.70 65556322.75 73273449.32 88178979.38 100729312.99
Sample 4 32607671.71 45135776.68 57790738.29 65402964.31 72930639.83 88161430.02 100906454.44
Sample 5 32876905.71 45101681.16 56814634.35 67263081.38 73307805.31 88304905.15 101326779.41
Sample 6 32755822.03 48739728.47 57049450.71 66348739.62 73688880.58 88437659.10 100563448.13
Sample 7 32771528.90 45599368.26 57393936.26 65403296.55 73612275.04 88497941.50 100631914.94
Sample 8 33070640.84 47039456.51 57142411.85 65564229.29 73420317.60 88444805.40 101170910.11
Sample 9 32654620.30 48341122.17 57514173.46 67151722.42 73724749.25 88322049.89 100883446.70
Sample 10 32631815.59 48752196.95 57451004.16 64586207.25 73709092.38 88268679.66 100632506.00
Sample 11 32860017.77 46483887.48 57560886.03 65559363.03 73251066.26 88245351.89 100873549.52
Sample 12 32596830.45 48364391.42 57094749.32 65324749.66 73355813.58 88133048.16 100671366.69
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Min 32596830.45 45101681.16 56814634.35 64586207.25 72930639.83 88133048.16 100563448.13
Max 33070640.84 48840662.72 57790738.29 68534511.01 73917352.31 88497941.50 101326779.41
Avg. 32766141.14 47491883.55 57319524.79 66008812.19 73450124.86 88304702.08 100853828.20
Meian 32763675.47 48352756.80 57347328.88 65557842.89 73388065.59 88293639.92 100878498.11
Median Per Core 8190918.87 8058792.80 7168416.11 6555784.29 6115672.13 5518352.50 5043924.91
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Rate(Avg.) 114.76% 109.72% 100.24% 101.55% 100.90% 100.24% 100.05%
Rate(Median) 112.51% 111.77% 100.08% 101.11% 100.89% 100.13% 100.12%
Rate(Max-Min) 129.92% 118.13% 103.56% 107.44% 102.25% 101.30% 100.94%
Rate(Min-Min) 128.06% 109.09% 101.81% 101.25% 100.88% 100.88% 100.18%
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
<2> MSI Claw A1m (Portable Gaming PC)
[CPU] Intel Core Ulta 7 155H (6 x P-core(with HT) / 8 x E-core / 2 x LP-E-core)
[Mem] 16 GByte
[Kernel Config] GENERIC
Use Cores 4 6 8 10 12 16 20
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Sample 1 24319693.18 37069136.11 45921995.46 54485526.18 56566147.38 68024423.22 78159568.62
Sample 2 25589225.26 41669088.69 45977899.31 54506959.32 57384862.76 68337574.33 78447780.54
Sample 3 25586922.09 42645292.11 46138062.77 51280417.53 58197891.49 72022788.30 78191400.25
Sample 4 29179466.49 37389152.53 47851676.89 51964975.01 57913054.35 70541327.51 78194399.76
Sample 5 21855879.01 37419611.09 44454651.84 52770288.72 59554056.20 68277789.77 79052097.88
Sample 6 23673156.00 39839577.05 44172040.51 52601540.92 59137001.18 68647186.84 78600593.77
Sample 7 23196636.09 36576006.61 42053712.91 52199376.03 56988358.27 67796573.75 78890296.36
Sample 8 28970812.67 39695680.29 43935088.97 51523776.41 59617326.25 68943847.79 78170732.83
Sample 9 29597036.14 33352986.36 46425543.05 54221461.94 56837440.35 68182722.20 78607245.00
Sample 10 33018330.82 37292093.95 50967296.81 52132996.00 57769476.84 66690456.02 78823448.32
Sample 11 32566936.82 33854111.39 50979431.99 48966749.94 58535738.88 69352365.96 78463652.20
Sample 12 23820817.50 32946634.39 46368285.58 52377177.22 57073149.28 68263636.32 78151237.23
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Min 21855879.01 32946634.39 42053712.91 48966749.94 56566147.38 66690456.02 78151237.23
Max 33018330.82 42645292.11 50979431.99 54506959.32 59617326.25 72022788.30 79052097.88
Avg. 26781242.67 37479114.21 46270473.84 52419270.44 57964541.94 68756724.33 78479371.06
Meian 25588073.68 37340623.24 46057981.04 52288276.63 57841265.60 68307682.05 78455716.37
Median Per Core 6397018.42 6223437.21 5757247.63 5228827.66 4820105.47 4269230.13 3922785.82
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
[Kernel Config] hmp(4) / intelhfi(4) enable + sched_ule(4) patched
Use Cores 4 6 8 10 12 16 20
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Sample 1 29394294.62 37624587.64 46054324.00 52087209.33 58585547.68 71290319.69 78854146.51
Sample 2 33146047.02 36243093.18 46294690.53 51000363.89 58611052.49 70885752.16 78296760.95
Sample 3 32975126.37 39274427.40 45876396.41 50855449.51 59270875.37 71067966.25 78627233.74
Sample 4 32797618.07 36582013.00 46984873.53 51005720.76 59007626.66 70994427.56 79196471.31
Sample 5 31378123.31 39556555.66 46672065.44 53601032.54 58749842.54 70875819.21 77753977.78
Sample 6 29794211.36 34646839.09 43934249.84 53278107.50 58023222.02 70559836.35 77981487.85
Sample 7 31868170.58 42300824.57 46494659.93 51415959.83 58907945.13 70930095.72 78239193.47
Sample 8 32863248.48 38695381.03 46394818.38 51578101.07 58464976.56 70731207.52 78174199.50
Sample 9 33347791.98 37617246.12 46873358.97 51653307.11 58521581.74 70733324.61 78803998.21
Sample 10 32992537.28 36668604.71 47047347.33 52033737.04 58694430.27 70739296.33 78298403.17
Sample 11 30423580.60 36303729.51 46185485.06 51056181.35 58972606.03 70603214.63 78392217.87
Sample 12 32487552.44 37355214.16 42491001.53 51769560.57 59041242.29 70675245.48 78636851.37
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Min 29394294.62 34646839.09 42491001.53 50855449.51 58023222.02 70559836.35 77753977.78
Max 33347791.98 42300824.57 47047347.33 53601032.54 59270875.37 71290319.69 79196471.31
Avg. 31955691.84 37739043.01 45941939.25 51777894.21 58737579.07 70840542.13 78437911.81
Meian 32642585.26 37486230.14 46344754.46 51615704.09 58722136.41 70807557.77 78345310.52
Median Per Core 8160646.31 6247705.02 5793094.31 5161570.41 4893511.37 4425472.36 3917265.53
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
Rate(Avg.) 119.32% 100.69% 99.29% 98.78% 101.33% 103.03% 99.95%
Rate(Median) 127.57% 100.39% 100.62% 98.71% 101.52% 103.66% 99.86%
Rate(Max-Min) 152.58% 128.39% 111.87% 109.46% 104.78% 106.90% 101.34%
Rate(Min-Min) 134.49% 105.16% 101.04% 103.86% 102.58% 105.80% 99.49%
-----------------+-------------+-------------+-------------+-------------+-------------+-------------+-------------
<<Evaluation of measurement results>>--------------------------------------------------------------------------------------
* When the number of cores used (number of execution threads) is less than 6 - specifically at 4 threads, which falls
within the physical P-core count - I observe an improvement of approximately 12?27% in median values.
Performance remains unchanged at 8 threads or more. Consequently, I consider this modification to be beneficial.
* This modification does not alter the scheduling algorithm itself but rather aims to maximize the utilization of
high-performance cores. Given this objective, the significant performance gains observed with thread counts below
the physical P-core limit indicate successful consolidation of processing onto the P-cores.
I attribute the particularly improvement seen in the Core Ultra 7 to the fact that LP-E cores are no longer utilized
in this scenario.
* Performance is maintained at 8 threads or more, where high-performance cores alone would be insufficient.
I believe this outcome - consistent with our intentions - results from the fact that the design philosophy and
algorithms of sched_ule(4) remain unchanged.
* During this benchmark run, the Core Ultra 7 triggers multiple dynamic updates to the intelhfi(4) HFI table based on
processing conditions, whereas the Core i7-1370p triggers no such updates.
I attribute this difference to manufacturer-specific UEFI (BIOS) configurations.
* On the Core Ultra 7, performance drops slightly below that of the GENERIC kernel (to 98?99%) at certain thread
counts of 8 or higher. While the exact cause remains unidentified, the timing coincides with dynamic updates to the
intelhfi(4) HFI table; I hypothesize that these updates may have triggered a shift to LP-E cores due to thermal
constraints.
* Although I have not conducted rigorous statistical testing, the sample data shows greater performance fluctuation
with the GENERIC kernel. We attribute the stabilization of these figures in the patched version to the effectiveness
of the above b).
## EoF ####################################################################################################################

File Metadata

Mime Type
text/plain
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
34501751
Default Alt Text
IntegrationStrategy_for_hmp_sched_ule_And_PerformanceImprovementReport.txt (37 KB)

Event Timeline