Re: [PATCH v2 0/8] uclamp sum aggregation

[Dietmar Eggemann]

On 10/03/2025 13:54, Hongyan Xia wrote:
> On 10/03/2025 11:34, Dietmar Eggemann wrote:
>> On 06/03/2025 12:38, Xuewen Yan wrote:
>>> On Thu, Mar 6, 2025 at 7:32 PM Hongyan Xia <hongyan.xia2@xxxxxxx> wrote:
>>>>
>>>> Hi Xuewen,
>>>>
>>>> On 06/03/2025 11:12, Xuewen Yan wrote:
>>>>> Hi Hongyan,
>>>>>
>>>>> On Tue, Mar 4, 2025 at 10:26 PM Hongyan Xia <hongyan.xia2@xxxxxxx>

[...]

>> Like I mentioned already in the original thread:
>>
>> https://lkml.kernel.org/r/65365ec7-6a16-4e66-8005-e78788cbedfa@xxxxxxx
>>
>> I would prefer that uclamp stays in core.c. ENQUEUE_DELAYED among all
>> the other flags is already used there (ttwu_runnable()).
>>
>> task_struct contains sched_{,rt_,dl_}entity}. We just have to be
>> careful when switching policies.
>>
>> -- 
>>
>> Could you also incorporate the changes in {en,de}queue_task_fair()
>> ((task_on_rq_migrating(p) || (flags & {RESTORE,DEQUEUE}_SAVE))) vs.
>> (!p->se.sched_delayed || (flags & ENQUEUE_DELAYED)) and
>> (!p->se.sched_delayed) so the uclamp-util_est relation is easier to spot?
>>
>> [...]
> 
> At the moment we can't do this. Sum aggregation was designed before
> delayed dequeue and it syncs with p->se.on_rq. If we sync with something
> else and take care of delayed dequeue cases (like util_est) then I have
> to rewrite part of the series.

Ah, OK! But this 'uclamp not in sync with util_est' is already an issue
on today's mainline so I would like to see this fixed as discreet as
possible and then another prep-patch for 'uclamp sum aggregation'.
IMHO, then it's clearer why we would need more rework in this area.