Wondering if searching and preempting needs will ever be conflicting?OK
I guess the winning point is that we don't commit behaviors to
userspace, but just abstract concepts which are turned into biases.
I don't see conflicts right now: if you are latency tolerant that
means you can spend more time to try finding a better CPU (e.g. we can
use the energy model to compare multiple CPUs) _and/or_ give the
current task a better chance to complete by delaying its preemption.
The issue I see is suppose we have a range of latency-nice values, then it
Otherwise sounds like a good direction to me. For the searching aspect, canI guess that's worth a try, only caveat I see is that it's turning the
we map latency nice values to the % of cores we search in select_idle_cpu?
Thus the search cost can be controlled by latency nice value.
bias into something very platform specific. Meaning, the same
latency-nice value on different machines can have very different
results.
Would not be better to try finding a more platform independent mapping?
Maybe something time bounded, e.g. the higher the latency-nice the more
time we can spend looking for CPUs?
I guess I got the definition of "latency tolerant" backwards.
But the issue is if more latency tolerant workloads set to lessI don't get this example: why more latency tolerant workloads should
search, we still need some mechanism to achieve good spread of
threads.
require less search?
If a workload has set it to low latency tolerant, then the search will be
Can we keep the sliding window mechanism in that case?Which one? Sorry did not went through the patches, can you briefly
resume the idea?
Doing it for select_idle_core will have the issue that the dynamic flag
Also will latency nice do anything for select_idle_core andI guess principle the same bias can be used at different levels, maybe
select_idle_smt?
with different mappings.
In the mobile world use-case we will likely use it only to switch from
select_idle_sibling to the energy aware slow path. And perhaps to see
if we can bias the wakeup preemption granularity.
Best,
Patrick