[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a9ed73a-256c-4ace-6b26-e30ac69cbdbc@arm.com>
Date: Wed, 7 Jun 2023 12:50:08 +0100
From: Hongyan Xia <hongyan.xia2@....com>
To: Qais Yousef <qyousef@...alina.io>
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
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?
Hongyan
Powered by blists - more mailing lists