Messages in this thread | | | Date | Mon, 18 Dec 2023 09:51:52 +0100 | Subject | Re: [PATCH 1/4] sched/fair: Be less aggressive in calling cpufreq_update_util() | From | Dietmar Eggemann <> |
| |
On 08/12/2023 02:52, Qais Yousef wrote: > Due to the way code is structured, it makes a lot of sense to trigger > cpufreq_update_util() from update_load_avg(). But this is too aggressive > as in most cases we are iterating through entities in a loop to > update_load_avg() in the hierarchy. So we end up sending too many > request in an loop as we're updating the hierarchy. > > Combine this with the rate limit in schedutil, we could end up > prematurely send up a wrong frequency update before we have actually > updated all entities appropriately. > > Be smarter about it by limiting the trigger to perform frequency updates > after all accounting logic has done. This ended up being in the
What are the boundaries of the 'accounting logic' here? Is this related to the update of all sched_entities and cfs_rq's involved when a task is attached/detached (or enqueued/dequeued)?
I can't see that there are any premature cfs_rq_util_change() in the current code when we consider this.
And avoiding updates for a smaller task to make sure updates for a bigger task go through is IMHO not feasible.
I wonder how much influence does this patch has on the test results presented the patch header?
> following points: > > 1. enqueue/dequeue_task_fair() > 2. throttle/unthrottle_cfs_rq() > 3. attach/detach_task_cfs_rq() > 4. task_tick_fair() > 5. __sched_group_set_shares() > > This is not 100% ideal still due to other limitations that might be > a bit harder to handle. Namely we can end up with premature update > request in the following situations: > > a. Simultaneous task enqueue on the CPU where 2nd task is bigger and > requires higher freq. The trigger to cpufreq_update_util() by the > first task will lead to dropping the 2nd request until tick. Or > another CPU in the same policy trigger a freq update. > > b. CPUs sharing a policy can end up with the same race in a but the > simultaneous enqueue happens on different CPUs in the same policy. > > The above though are limitations in the governor/hardware, and from > scheduler point of view at least that's the best we can do. The > governor might consider smarter logic to aggregate near simultaneous > request and honour the higher one.
[...]
| |