[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1f8c50f2-6530-49bd-9b41-744437078100@arm.com>
Date: Mon, 27 May 2024 00:52:54 +0200
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Hongyan Xia <hongyan.xia2@....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 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?
[...]
Powered by blists - more mailing lists