Re: Uclamp races due to non-atomic static_branch_likely updates

[Qais Yousef]

On 10/22/26 14:18, Christian Loehle wrote:

> So I guess the clear-when-entering-idle taper is sufficient for UCLAMP_MIN.
> UCLAMP_MAX (where on a sufficiently low setting we may just never have that
> idle entry to clear) we expect to be fine because it's max-aggregated, i.e.
> a second task would let us escape the low stale UCLAMP_MAX on the rq?

I am not sure I got you. We should eventually go to idle and reset the 
settings. But you made me realize the unconditional reset could break 
the saved uclamp max at idle :-/ I could either unconditionally set both 
uclamp_{min, max} to 0, or just have some conditions to do_once when 
uclamp_is_used(). I prefer setting to 0, but this is a change in behavior.

> I guess we could reevaluate the static branch at every tick too if we really
> care?

It seems you are worried about the temporary corrupt state after boot 
(first uclamp use more precisely) where there's no idle time, right? I 
think we can live with that.