I'm facing some challenges while working on making IntelHFI compatible with HMP, and I'd like to ask for your advice.

It seems that the current HMP mechanism doesn't allow for dynamic loading of providers like intelhfi using kldload.
I understand that the probe() and init() callbacks registered with HMP_PROVIDER_DECLARE are called only when HMP is initialized during the initial stages of kernel startup, and they evaluate which provider to use.

I understand that HMP providers don't require dynamic loading or unloading for their purpose, hence this approach. Is my understanding correct?

(Currently, intelhfi is being developed as a device driver, so changing to this approach would require some adjustments.)

In D56547#1296220, @koinec_yahoo.co.jp wrote:

It seems that the current HMP mechanism doesn't allow for dynamic loading of providers like intelhfi using kldload.
I understand that the probe() and init() callbacks registered with HMP_PROVIDER_DECLARE are called only when HMP is initialized during the initial stages of kernel startup, and they evaluate which provider to use.

I understand that HMP providers don't require dynamic loading or unloading for their purpose, hence this approach. Is my understanding correct?

(Currently, intelhfi is being developed as a device driver, so changing to this approach would require some adjustments.)

Yes. The reason is that this will be integrated with scheduler later, and I haven't found a good approach to kldload/kldunload on runtime without confusing the scheduler.

Thank you very much for improving HMP.

Excuse me, but I have a problem regarding how to make intelhfi compatible with HMP, and I'd like to ask for your advice.

• The hmp_init() provider function is currently of type void and does not receive a return value. However, intelhfi's initialization allocates memory for things like the table cache area, and it can fail. Therefore, I'm thinking of implementing a mechanism where, if the intelhfi's _init() provider function fails, it returns a non-zero integer, and the HMP side calls hmp_default_init() to fall back into that state. What do you think?
• By supporting hmp_init(), intelhfi will no longer need the _probe() and _attach() functions as a device driver. In other words, the provider does not need to be a device driver. Therefore, I'm thinking of creating a directory called sys/amd64/hmp under sys/dev/intelhfi/ and moving the provider there. This way, when HFI for AMD processors is implemented later, it can also be placed there. This is a difficult decision as it will affect the future policies of HMP providers. What are your thoughts?
• The recent revision of HMP has eliminated consideration of CLASS. Could you please explain the reasoning behind this?
• In the current latest code, the Capacity provider and Score provider are separated, but the default routine for the Score provider appears to be missing. Is it correct to understand this is because providers like intelhfi always implement this? Even if this understanding is correct, I believe the 'default_score_init()' function is necessary for cases where no provider exists.
• I understand that Capacity is used for load balancing, and that HMP internally calculates it from the maximum score of each core provided by each score provider. Therefore, I understand that there are no cases where the Capacity and Score providers are different. Is my understanding incorrect? If possible, please explain the cases where the Capacity and Score providers are different. (Or is it correct to understand that the Score provider is usually implemented by intelhfi, and the Capacity provider usually uses the default?)

• The hmp_init() provider function is currently of type void and does not receive a return value. However, intelhfi's initialization allocates memory for things like the table cache area, and it can fail. Therefore, I'm thinking of implementing a mechanism where, if the intelhfi's _init() provider function fails, it returns a non-zero integer, and the HMP side calls hmp_default_init() to fall back into that state. What do you think?

Right, I'll add return value for init() and if it fails, provider with next lower priority will do their init(), and so on.

• By supporting hmp_init(), intelhfi will no longer need the _probe() and _attach() functions as a device driver. In other words, the provider does not need to be a device driver. Therefore, I'm thinking of creating a directory called sys/amd64/hmp under sys/dev/intelhfi/ and moving the provider there. This way, when HFI for AMD processors is implemented later, it can also be placed there. This is a difficult decision as it will affect the future policies of HMP providers. What are your thoughts?

Device driver probe() and hmp probe() are different things. E.g. even if the provider isn't selected, you might want to report what it gets (e.g. score) through sysctl. So please keep it as device driver for now.

• The recent revision of HMP has eliminated consideration of CLASS. Could you please explain the reasoning behind this?

hmp(4) exists for schedulers. In other words, if something is too excessive or too much provider-dependent and not used by scheduler, it shouldn't be processed by hmp(4) at all. Different providers might have different CLASS, and making hmp(4) contain info regarding all those classes will be excessive. In fact, the scheduler only needs performance and efficient scores which are stored in hmp_pcpu struct.

If a provider has a class other than perf/eff, then it can be displayed through provider's sysctl, but hmp(4) and scheduler doesn't need that info.

• In the current latest code, the Capacity provider and Score provider are separated, but the default routine for the Score provider appears to be missing. Is it correct to understand this is because providers like intelhfi always implement this? Even if this understanding is correct, I believe the 'default_score_init()' function is necessary for cases where no provider exists.

Capacity is for load balancing. Because scheduler will use (individual capacity of core)/(total capacity) a lot, we'll need if (has_capacity) many places without default capacity provider. Although the default capacity provider is called "provider", it's nothing more than filling static values into capacity field.

Now, score is used for thread preference (e.g. when there is new thread/load balancing, which core should take the thread?). In this case, having if (has_scores) is better because 1) we only have few places that need this logic and 2) with if (has_scores), we can fall back to capacities so cores with larger capacity can take the thread. Please note that core with larger capacity is always better choice for new threads, but I believe it is in most cases (benchmark is needed).

• I understand that Capacity is used for load balancing, and that HMP internally calculates it from the maximum score of each core provided by each score provider. Therefore, I understand that there are no cases where the Capacity and Score providers are different. Is my understanding incorrect? If possible, please explain the cases where the Capacity and Score providers are different. (Or is it correct to understand that the Score provider is usually implemented by intelhfi, and the Capacity provider usually uses the default?)

Device trees is capacity-only, while SCMI is score-only. The separation of capacity and score providers is for cases like having device tree as capacity provider and SCMI as score providers. On intelhfi, this is trivial.