[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230630114403.ptbdy63ugmchr4hx@airbuntu>
Date: Fri, 30 Jun 2023 12:44:03 +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 completely have this series paged out now. I'll consider this comment when
I prepare v3 - which I hope I'll have some down time in few weeks time to send
some fixes I have been sitting on for a bit.
Cheers
--
Qais Yousef
Powered by blists - more mailing lists