All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Valentin Schneider <valentin.schneider@arm.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Patrick Bellasi <patrick.bellasi@matbug.net>,
	Quentin Perret <qperret@google.com>,
	Qais Yousef <qais.yousef@arm.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>
Subject: Re: [PATCH v2 1/4] sched/uclamp: Make uclamp_util_*() helpers use and return UL values
Date: Wed, 4 Dec 2019 18:29:09 +0100	[thread overview]
Message-ID: <CAKfTPtDg2_Yc98o9SpUjm-qZw3bQ8d_zFJ9PL31EnFy2u_4_mA@mail.gmail.com> (raw)
In-Reply-To: <2a244463-8010-ccf4-dc33-80831265ba9a@arm.com>

On Wed, 4 Dec 2019 at 18:15, Valentin Schneider
<valentin.schneider@arm.com> wrote:
>
> On 04/12/2019 16:12, Vincent Guittot wrote:
> > On Wed, 4 Dec 2019 at 17:03, Valentin Schneider
> > <valentin.schneider@arm.com> wrote:
> >>
> >> On 04/12/2019 15:22, Vincent Guittot wrote:
> >>>> @@ -2303,15 +2303,15 @@ static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) {}
> >>>>  unsigned int uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id);
> >>>
> >>> Why not changing uclamp_eff_value to return unsigned long too ? The
> >>> returned value represents a utilization to be compared with other
> >>> utilization value
> >>>
> >>
> >> IMO uclamp_eff_value() is a simple accessor to uclamp_se.value
> >> (unsigned int), which is why I didn't want to change its return type.
> >> I see it as being the task equivalent of rq->uclamp[clamp_id].value, IOW
> >> "give me the uclamp value for that clamp index". It just happens to be a
> >> bit more intricate for tasks than for rqs.
> >
> > But then you have to take care of casting the returned value in
> > several places here and in patch 3
> >
>
> True. I'm not too hot on having to handle rq clamp values
> (rq->uclamp[x].value) and task clamp values (uclamp_eff_value())
> differently (cast one but not the other), but I don't feel *too* strongly
> about this, so if you want I can do that change for v3.

Yes please. This makes the code easier to read and understand.

The rest of the patch series looks good to me. So feel free to add my
reviewed by on the next version
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>

>
> >>
> >> uclamp_util() & uclamp_util_with() do explicitly return a utilization,
> >> so here it makes sense (in my mind, that is) to return UL.

  reply	other threads:[~2019-12-04 17:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-03 15:59 [PATCH v2 0/4] sched/fair: Task placement biasing using uclamp Valentin Schneider
2019-12-03 15:59 ` [PATCH v2 1/4] sched/uclamp: Make uclamp_util_*() helpers use and return UL values Valentin Schneider
2019-12-04 15:22   ` Vincent Guittot
2019-12-04 16:03     ` Valentin Schneider
2019-12-04 16:12       ` Vincent Guittot
2019-12-04 16:25         ` Rainer Sickinger
2019-12-04 17:15         ` Valentin Schneider
2019-12-04 17:29           ` Vincent Guittot [this message]
2019-12-04 17:35             ` Valentin Schneider
2019-12-10 18:09   ` Dietmar Eggemann
2019-12-10 18:31     ` Valentin Schneider
2019-12-03 15:59 ` [PATCH v2 2/4] sched/uclamp: Rename uclamp_util_*() into uclamp_rq_util_*() Valentin Schneider
2019-12-03 15:59 ` [PATCH v2 3/4] sched/fair: Make task_fits_capacity() consider uclamp restrictions Valentin Schneider
2019-12-10 17:07   ` Dietmar Eggemann
2019-12-10 17:10     ` Valentin Schneider
2019-12-03 15:59 ` [PATCH v2 4/4] sched/fair: Make feec() " Valentin Schneider
2019-12-10 18:23   ` Dietmar Eggemann
2019-12-10 18:35     ` Valentin Schneider

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKfTPtDg2_Yc98o9SpUjm-qZw3bQ8d_zFJ9PL31EnFy2u_4_mA@mail.gmail.com \
    --to=vincent.guittot@linaro.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=patrick.bellasi@matbug.net \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=qperret@google.com \
    --cc=valentin.schneider@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.