[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0387ac04-2dbe-4a73-975a-078a18554654@arm.com>
Date: Tue, 28 May 2024 12:42:48 +0100
From: Hongyan Xia <hongyan.xia2@....com>
To: Dietmar Eggemann <dietmar.eggemann@....com>,
Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Juri Lelli <juri.lelli@...hat.com>, Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Valentin Schneider <vschneid@...hat.com>
Cc: Qais Yousef <qyousef@...alina.io>,
Morten Rasmussen <morten.rasmussen@....com>,
Lukasz Luba <lukasz.luba@....com>,
Christian Loehle <christian.loehle@....com>, pierre.gondois@....com,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v3 5/6] sched/uclamp: Simplify uclamp_eff_value()
On 26/05/2024 23:52, Dietmar Eggemann wrote:
> On 07/05/2024 14:50, Hongyan Xia wrote:
>
> [...]
>
>> +static inline unsigned long uclamp_eff_value(struct task_struct *p,
>> + enum uclamp_id clamp_id)
>> +{
>> + if (uclamp_is_used() && p->uclamp[clamp_id].active)
>> + return p->uclamp[clamp_id].value;
>> +
>> + if (clamp_id == UCLAMP_MIN)
>> + return 0;
>> +
>> + return SCHED_CAPACITY_SCALE;
>
> Why not keep using 'return uclamp_none(clamp_id)' here?
Reason is that uclamp_none() is in core.c.
I could move uclamp_none() into sched.h if needed.
Powered by blists - more mailing lists