Of course, choosing a core to execute a thread when cores have different performance and efficiency characteristics is not only an optimization process, as many degrees of liberty remain (consider the simple example of a single thread and two available cores, a P and a E one; which one to choose?). This selection must then be guided by specific policies decided by the administrator/user.

Currently, it is possible to use cpuset(1) to restrict threads/processes (and other objects) to a specific subset of cores. Each cpuset holds a mask designating the allowed cores (and domains, but we are not concerned with that here). Cpusets are useful for a number of reasons, in general to get more performance and more predictability (soft real-time), more specifically by, e.g., moving compute threads next to where data appears (such as NICs and their interrupts), reducing the overhead of thread migration, partitioning the system, etc. cpusets form a tree where each node restricts the mask of its descendants, allowing to . Specific "root" cpusets apply to the whole system and each jail, allowing to restrict jail processes to some cores only.

Performance/efficiency policies are conceptually different than cpusets, as the latter only say which cores are allowed, but not which ones should be actually chosen. Directly mapping policies to cpuset masks would lead to a number of practical problems, for example:

1. Only trivial policies could be implemented.
2. Changing a policy would amount to changing a mask, which needs to be propagated downwards the cpuset tree, possibly further restricting the policy's mask, to the point where no CPUs are actually available at some nodes.

That said, we may want to leverage the cpuset tree structure and the fact that interesting objects are already tagged with cpusets, by attaching a policy to a struct cpuset. Cpusets down the tree would only be able to further restrict parent policies, which implies that we must establish an ordering of policies.

Managing policies independently of cpuset masks allows to define partitions where each set comprises different types of cores, inside which the selected policy can apply. This seems to give maximum flexibility, where the administrator can still decide to forcibly rule out some cores for some threads, but also enjoy the benefits of some performance/efficiency policy, establish different policies for different system partitions, etc.

Among the possible policies, there should be at least a maximum performance one: All cores are kept busy when possible, and if not all can (not enough threads to run in parallel), the most performant ones are used in priority. Of course, there cannot be a maximum efficiency one without any other constraint (that would be equivalent to turning the computer off :-)). This is where optimization comes into play: Trying to keep the same performance, or degrading it slightly, while consuming less power, or conversely, reducing power consumption and in this envelope trying to reach maximum performance.

Nobody wants to reduce performance without reasons, so it seems that what is needed is some kind of efficiency control value. Let's say we define a scale without unit from 0 to 100 (this is arbitrary at this point, and just to get more concrete). Maximum efficiency would be 100, and we would define it as running threads only on the "lower" type of available cores (E or LP-E for Intel CPUs). Minimum efficiency (0) would correspond to maximum performance as explained above. As the value grows from 0, we would allow higher ratio of use of more performant cores to the most efficient ones (so we need a suitable mathematical function that grows and sends 0 to 0 and 100 to infinity, and probably sends 50 to 1; in practice, though, the ratios towards 0 would be discretized to avoid inefficiencies). The single value model is perhaps too simplistic when there are more than two types of cores; it may be desirable to have one such value per type of core, except for the most efficient type (this one being the base).

Processes/threads that should never consume too much power or, in the case of Meteor Lake, should not wake the compute tile, would be put in an appropriate cpuset whose policy completely rules out running on anything else than the most efficient cores. Those processes/threads may include power management daemon (e.g., powerd), interrupts for low speed devices, etc.

Interrupts