[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230717214923.hhypecamvpvb5uao@airbuntu>
Date: Mon, 17 Jul 2023 22:49:23 +0100
From: Qais Yousef <qyousef@...alina.io>
To: Hongyan Xia <hongyan.xia2@....com>
Cc: Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
linux-kernel@...r.kernel.org, Lukasz Luba <lukasz.luba@....com>,
Wei Wang <wvw@...gle.com>, Xuewen Yan <xuewen.yan94@...il.com>,
Hank <han.lin@...iatek.com>,
Jonathan JMChen <Jonathan.JMChen@...iatek.com>,
Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH v2 1/3] sched/uclamp: Set max_spare_cap_cpu even if
max_spare_cap is 0
On 06/07/23 12:50, Hongyan Xia wrote:
> Hi Qais,
>
> On 2023-02-11 17:28, Qais Yousef wrote:
> > On 02/07/23 10:45, Vincent Guittot wrote:
> > > [...]
> >
> > Isn't it better to go back to v1 form then? The inconsistent type paired with
> > the cast isn't getting too ugly for me :(
> >
> > I don't think we can convert cpu_cap to long without having to do more work as
> > it is used with 'util'.
>
> Sorry if I'm missing something obvious, but why can't we convert util to
> long? The only place I see which mixes with util is
>
> lsub_positive(&cpu_cap, util);
>
> but at this point both cpu_cap and util should have sane values (top bit not
> set) so doing clamped subtraction should just work fine?
I think all options are not very pretty. But the least evil is what Vincent
suggested to simply do the cast in this one place. Util is used in more places
and assumed to be unsigned long, so chances of unhappy accidents are higher and
I don't feel like auditing more code for correctness given we have a simple
straightforward alternative now :)
Thanks
--
Qais Yousef
Powered by blists - more mailing lists