Re: [PATCH 00/24] Complete EEVDF

From: Luis Machado
Date: Wed Nov 06 2024 - 07:07:21 EST


Hi,

On 11/6/24 11:09, Peter Zijlstra wrote:
> On Wed, Nov 06, 2024 at 11:49:00AM +0530, K Prateek Nayak wrote:
>
>> Since delayed entities are still on the runqueue, they can affect PELT
>> calculation. Vincent and Dietmar have both noted this and Peter posted
>> https://lore.kernel.org/lkml/172595576232.2215.18027704125134691219.tip-bot2@tip-bot2/
>> in response but it was pulled out since Luis reported observing -ve
>> values for h_nr_delayed on his setup. A lot has been fixed around
>> delayed dequeue since and I wonder if now would be the right time to
>> re-attempt h_nr_delayed tracking.
>
> Yeah, it's something I meant to get back to. I think the patch as posted
> was actually right and it didn't work for Luis because of some other,
> since fixed issue.
>
> But I might be misremembering things. I'll get to it eventually :/

Sorry for the late reply, I got sidetracked on something else.

There have been a few power regressions (based on our Pixel6-based testing) due
to the delayed-dequeue series.

The main one drove the frequencies up due to an imbalance in the uclamp inc/dec
handling. That has since been fixed by "[PATCH 10/24] sched/uclamg: Handle delayed dequeue". [1]

The bug also made it so disabling DELAY_DEQUEUE at runtime didn't fix things, because the
imbalance/stale state would be perpetuated. Disabling DELAY_DEQUEUE before boot did fix things.

So power use was brought down by the above fix, but some issues still remained, like the
accounting issues with h_nr_running and not taking sched_delayed tasks into account.

Dietmar addressed some of it with "kernel/sched: Fix util_est accounting for DELAY_DEQUEUE". [2]

Peter sent another patch to add accounting for sched_delayed tasks [3]. Though the patch was
mostly correct, under some circumstances [4] we spotted imbalances in the sched_delayed
accounting that slowly drove frequencies up again.

If I recall correctly, Peter has pulled that particular patch from the tree, but we should
definitely revisit it with a proper fix for the imbalance. Suggestion in [5].

[1] https://lore.kernel.org/lkml/20240727105029.315205425@xxxxxxxxxxxxx/
[2] https://lore.kernel.org/lkml/c49ef5fe-a909-43f1-b02f-a765ab9cedbf@xxxxxxx/
[3] https://lore.kernel.org/lkml/172595576232.2215.18027704125134691219.tip-bot2@tip-bot2/
[4] https://lore.kernel.org/lkml/6df12fde-1e0d-445f-8f8a-736d11f9ee41@xxxxxxx/
[5] https://lore.kernel.org/lkml/6df12fde-1e0d-445f-8f8a-736d11f9ee41@xxxxxxx/