All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] sched/uclamp: Fix overzealous type replacement
@ 2019-11-13 16:53 Valentin Schneider
  2019-11-14 20:28 ` Qais Yousef
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Valentin Schneider @ 2019-11-13 16:53 UTC (permalink / raw)
  To: linux-kernel
  Cc: mingo, peterz, vincent.guittot, Dietmar.Eggemann, tj,
	patrick.bellasi, surenb, qperret

Some uclamp helpers had their return type changed from 'unsigned int' to
'enum uclamp_id' by commit

  0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")

but it happens that some *actually* do return an unsigned int value. Those
are the helpers that return a utilization value: uclamp_rq_max_value() and
uclamp_eff_value(). Fix those up.

Note that this doesn't lead to any obj diff using a relatively recent
aarch64 compiler (8.3-2019.03). The current code of e.g. uclamp_eff_value()
already figures out that the return value is 11 bits (bits_per(1024)) and
doesn't seem to do anything funny. I'm still marking this as fixing the
above commit to be on the safe side.

Fixes: 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
---
 kernel/sched/core.c  | 4 ++--
 kernel/sched/sched.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 513a4794ff36..71a45025cd2e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -853,7 +853,7 @@ static inline void uclamp_idle_reset(struct rq *rq, enum uclamp_id clamp_id,
 }
 
 static inline
-enum uclamp_id uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id,
+unsigned int uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id,
 				   unsigned int clamp_value)
 {
 	struct uclamp_bucket *bucket = rq->uclamp[clamp_id].bucket;
@@ -918,7 +918,7 @@ uclamp_eff_get(struct task_struct *p, enum uclamp_id clamp_id)
 	return uc_req;
 }
 
-enum uclamp_id uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id)
+unsigned int uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id)
 {
 	struct uclamp_se uc_eff;
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 05c282775f21..280a3c735935 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2300,7 +2300,7 @@ static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) {}
 #endif /* CONFIG_CPU_FREQ */
 
 #ifdef CONFIG_UCLAMP_TASK
-enum uclamp_id uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id);
+unsigned int uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id);
 
 static __always_inline
 unsigned int uclamp_util_with(struct rq *rq, unsigned int util,
-- 
2.22.0


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] sched/uclamp: Fix overzealous type replacement
  2019-11-13 16:53 [PATCH] sched/uclamp: Fix overzealous type replacement Valentin Schneider
@ 2019-11-14 20:28 ` Qais Yousef
  2019-11-15  0:05   ` Valentin Schneider
  2019-11-15  8:12 ` Vincent Guittot
  2019-11-15 18:13 ` [tip: sched/urgent] " tip-bot2 for Valentin Schneider
  2 siblings, 1 reply; 8+ messages in thread
From: Qais Yousef @ 2019-11-14 20:28 UTC (permalink / raw)
  To: Valentin Schneider
  Cc: linux-kernel, mingo, peterz, vincent.guittot, Dietmar.Eggemann,
	tj, patrick.bellasi, surenb, qperret

On 11/13/19 16:53, Valentin Schneider wrote:
> Some uclamp helpers had their return type changed from 'unsigned int' to
> 'enum uclamp_id' by commit
> 
>   0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
> 
> but it happens that some *actually* do return an unsigned int value. Those
> are the helpers that return a utilization value: uclamp_rq_max_value() and
> uclamp_eff_value(). Fix those up.
> 
> Note that this doesn't lead to any obj diff using a relatively recent
> aarch64 compiler (8.3-2019.03). The current code of e.g. uclamp_eff_value()
> already figures out that the return value is 11 bits (bits_per(1024)) and
> doesn't seem to do anything funny. I'm still marking this as fixing the
> above commit to be on the safe side.
> 
> Fixes: 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> ---

The changelog could be a bit simpler and more explicitly say 0413d7f33e60
wrongly changed the return type of some functions. For a second I thought
something weird is going inside these functions.

But that could be just me :-)

Reviewed-by: Qais Yousef <qais.yousef@arm.com>

Thanks!

--
Qais Yousef

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] sched/uclamp: Fix overzealous type replacement
  2019-11-14 20:28 ` Qais Yousef
@ 2019-11-15  0:05   ` Valentin Schneider
  2019-11-15  9:05     ` Qais Yousef
  0 siblings, 1 reply; 8+ messages in thread
From: Valentin Schneider @ 2019-11-15  0:05 UTC (permalink / raw)
  To: Qais Yousef
  Cc: linux-kernel, mingo, peterz, vincent.guittot, Dietmar.Eggemann,
	tj, patrick.bellasi, surenb, qperret

On 14/11/2019 20:28, Qais Yousef wrote:
> On 11/13/19 16:53, Valentin Schneider wrote:
>> Some uclamp helpers had their return type changed from 'unsigned int' to
>> 'enum uclamp_id' by commit
>>
>>   0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
>>
>> but it happens that some *actually* do return an unsigned int value. Those
>> are the helpers that return a utilization value: uclamp_rq_max_value() and
>> uclamp_eff_value(). Fix those up.
>>
>> Note that this doesn't lead to any obj diff using a relatively recent
>> aarch64 compiler (8.3-2019.03). The current code of e.g. uclamp_eff_value()
>> already figures out that the return value is 11 bits (bits_per(1024)) and
>> doesn't seem to do anything funny. I'm still marking this as fixing the
>> above commit to be on the safe side.
>>
>> Fixes: 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
>> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
>> ---
> 
> The changelog could be a bit simpler and more explicitly say 0413d7f33e60
> wrongly changed the return type of some functions. For a second I thought
> something weird is going inside these functions.
> 

The first paragraph is exactly that, no? The rest (that starts with "Note
that") is just optional stuff I look into because I was curious.

> But that could be just me :-)
> 
> Reviewed-by: Qais Yousef <qais.yousef@arm.com>
> 
> Thanks!
> 
> --
> Qais Yousef
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] sched/uclamp: Fix overzealous type replacement
  2019-11-13 16:53 [PATCH] sched/uclamp: Fix overzealous type replacement Valentin Schneider
  2019-11-14 20:28 ` Qais Yousef
@ 2019-11-15  8:12 ` Vincent Guittot
  2019-11-15  9:09   ` Qais Yousef
  2019-11-15  9:55   ` Valentin Schneider
  2019-11-15 18:13 ` [tip: sched/urgent] " tip-bot2 for Valentin Schneider
  2 siblings, 2 replies; 8+ messages in thread
From: Vincent Guittot @ 2019-11-15  8:12 UTC (permalink / raw)
  To: Valentin Schneider
  Cc: linux-kernel, Ingo Molnar, Peter Zijlstra, Dietmar Eggemann,
	Tejun Heo, Patrick Bellasi, Suren Baghdasaryan, Quentin Perret

On Wed, 13 Nov 2019 at 17:55, Valentin Schneider
<valentin.schneider@arm.com> wrote:
>
> Some uclamp helpers had their return type changed from 'unsigned int' to
> 'enum uclamp_id' by commit
>
>   0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
>
> but it happens that some *actually* do return an unsigned int value. Those
> are the helpers that return a utilization value: uclamp_rq_max_value() and
> uclamp_eff_value(). Fix those up.
>
> Note that this doesn't lead to any obj diff using a relatively recent
> aarch64 compiler (8.3-2019.03). The current code of e.g. uclamp_eff_value()
> already figures out that the return value is 11 bits (bits_per(1024)) and
> doesn't seem to do anything funny. I'm still marking this as fixing the
> above commit to be on the safe side.
>
> Fixes: 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> ---
>  kernel/sched/core.c  | 4 ++--
>  kernel/sched/sched.h | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 513a4794ff36..71a45025cd2e 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -853,7 +853,7 @@ static inline void uclamp_idle_reset(struct rq *rq, enum uclamp_id clamp_id,
>  }
>
>  static inline
> -enum uclamp_id uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id,
> +unsigned int uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id,
>                                    unsigned int clamp_value)
>  {
>         struct uclamp_bucket *bucket = rq->uclamp[clamp_id].bucket;
> @@ -918,7 +918,7 @@ uclamp_eff_get(struct task_struct *p, enum uclamp_id clamp_id)
>         return uc_req;
>  }
>
> -enum uclamp_id uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id)
> +unsigned int uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id)
>  {
>         struct uclamp_se uc_eff;
>

And static inline enum uclamp_id uclamp_none(enum uclamp_id clamp_id) ?

Should it be fixed as well as it can return SCHED_CAPACITY_SCALE ?



> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 05c282775f21..280a3c735935 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -2300,7 +2300,7 @@ static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) {}
>  #endif /* CONFIG_CPU_FREQ */
>
>  #ifdef CONFIG_UCLAMP_TASK
> -enum uclamp_id uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id);
> +unsigned int uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id);
>
>  static __always_inline
>  unsigned int uclamp_util_with(struct rq *rq, unsigned int util,
> --
> 2.22.0
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] sched/uclamp: Fix overzealous type replacement
  2019-11-15  0:05   ` Valentin Schneider
@ 2019-11-15  9:05     ` Qais Yousef
  0 siblings, 0 replies; 8+ messages in thread
From: Qais Yousef @ 2019-11-15  9:05 UTC (permalink / raw)
  To: Valentin Schneider
  Cc: linux-kernel, mingo, peterz, vincent.guittot, Dietmar.Eggemann,
	tj, patrick.bellasi, surenb, qperret

On 11/15/19 00:05, Valentin Schneider wrote:
> On 14/11/2019 20:28, Qais Yousef wrote:
> > On 11/13/19 16:53, Valentin Schneider wrote:
> >> Some uclamp helpers had their return type changed from 'unsigned int' to
> >> 'enum uclamp_id' by commit
> >>
> >>   0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
> >>
> >> but it happens that some *actually* do return an unsigned int value. Those
> >> are the helpers that return a utilization value: uclamp_rq_max_value() and
> >> uclamp_eff_value(). Fix those up.
> >>
> >> Note that this doesn't lead to any obj diff using a relatively recent
> >> aarch64 compiler (8.3-2019.03). The current code of e.g. uclamp_eff_value()
> >> already figures out that the return value is 11 bits (bits_per(1024)) and
> >> doesn't seem to do anything funny. I'm still marking this as fixing the
> >> above commit to be on the safe side.
> >>
> >> Fixes: 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
> >> Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> >> ---
> > 
> > The changelog could be a bit simpler and more explicitly say 0413d7f33e60
> > wrongly changed the return type of some functions. For a second I thought
> > something weird is going inside these functions.
> > 
> 
> The first paragraph is exactly that, no? The rest (that starts with "Note
> that") is just optional stuff I look into because I was curious.

The way it read to me is that the function was returning uclamp_id as unsigned
int, hence my confusion/comment. Anyway, it's not a big deal. It's not really
a problem.

Thanks

--
Qais Yousef

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] sched/uclamp: Fix overzealous type replacement
  2019-11-15  8:12 ` Vincent Guittot
@ 2019-11-15  9:09   ` Qais Yousef
  2019-11-15  9:55   ` Valentin Schneider
  1 sibling, 0 replies; 8+ messages in thread
From: Qais Yousef @ 2019-11-15  9:09 UTC (permalink / raw)
  To: Vincent Guittot
  Cc: Valentin Schneider, linux-kernel, Ingo Molnar, Peter Zijlstra,
	Dietmar Eggemann, Tejun Heo, Patrick Bellasi, Suren Baghdasaryan,
	Quentin Perret

On 11/15/19 09:12, Vincent Guittot wrote:
> On Wed, 13 Nov 2019 at 17:55, Valentin Schneider
> <valentin.schneider@arm.com> wrote:
> >
> > Some uclamp helpers had their return type changed from 'unsigned int' to
> > 'enum uclamp_id' by commit
> >
> >   0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
> >
> > but it happens that some *actually* do return an unsigned int value. Those
> > are the helpers that return a utilization value: uclamp_rq_max_value() and
> > uclamp_eff_value(). Fix those up.
> >
> > Note that this doesn't lead to any obj diff using a relatively recent
> > aarch64 compiler (8.3-2019.03). The current code of e.g. uclamp_eff_value()
> > already figures out that the return value is 11 bits (bits_per(1024)) and
> > doesn't seem to do anything funny. I'm still marking this as fixing the
> > above commit to be on the safe side.
> >
> > Fixes: 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
> > Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
> > ---
> >  kernel/sched/core.c  | 4 ++--
> >  kernel/sched/sched.h | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 513a4794ff36..71a45025cd2e 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -853,7 +853,7 @@ static inline void uclamp_idle_reset(struct rq *rq, enum uclamp_id clamp_id,
> >  }
> >
> >  static inline
> > -enum uclamp_id uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id,
> > +unsigned int uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id,
> >                                    unsigned int clamp_value)
> >  {
> >         struct uclamp_bucket *bucket = rq->uclamp[clamp_id].bucket;
> > @@ -918,7 +918,7 @@ uclamp_eff_get(struct task_struct *p, enum uclamp_id clamp_id)
> >         return uc_req;
> >  }
> >
> > -enum uclamp_id uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id)
> > +unsigned int uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id)
> >  {
> >         struct uclamp_se uc_eff;
> >
> 
> And static inline enum uclamp_id uclamp_none(enum uclamp_id clamp_id) ?
> 
> Should it be fixed as well as it can return SCHED_CAPACITY_SCALE ?

Indeed. That should return unsigned int too as it's returning the uclamp value.

Thanks

--
Qais Yousef

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] sched/uclamp: Fix overzealous type replacement
  2019-11-15  8:12 ` Vincent Guittot
  2019-11-15  9:09   ` Qais Yousef
@ 2019-11-15  9:55   ` Valentin Schneider
  1 sibling, 0 replies; 8+ messages in thread
From: Valentin Schneider @ 2019-11-15  9:55 UTC (permalink / raw)
  To: Vincent Guittot
  Cc: linux-kernel, Ingo Molnar, Peter Zijlstra, Dietmar Eggemann,
	Tejun Heo, Patrick Bellasi, Suren Baghdasaryan, Quentin Perret

On 15/11/2019 08:12, Vincent Guittot wrote:
> 
> And static inline enum uclamp_id uclamp_none(enum uclamp_id clamp_id) ?
> 
> Should it be fixed as well as it can return SCHED_CAPACITY_SCALE ?
> 

Right, thanks for staring at this. I'll go double check the diff and fix up
any strays.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [tip: sched/urgent] sched/uclamp: Fix overzealous type replacement
  2019-11-13 16:53 [PATCH] sched/uclamp: Fix overzealous type replacement Valentin Schneider
  2019-11-14 20:28 ` Qais Yousef
  2019-11-15  8:12 ` Vincent Guittot
@ 2019-11-15 18:13 ` tip-bot2 for Valentin Schneider
  2 siblings, 0 replies; 8+ messages in thread
From: tip-bot2 for Valentin Schneider @ 2019-11-15 18:13 UTC (permalink / raw)
  To: linux-tip-commits
  Cc: Valentin Schneider, Peter Zijlstra (Intel),
	Qais Yousef, Dietmar.Eggemann, Linus Torvalds, Thomas Gleixner,
	patrick.bellasi, qperret, surenb, tj, vincent.guittot,
	Ingo Molnar, Borislav Petkov, linux-kernel

The following commit has been merged into the sched/urgent branch of tip:

Commit-ID:     16d6bbe7982e99f7f326ec6f088c0aaf85efa69d
Gitweb:        https://git.kernel.org/tip/16d6bbe7982e99f7f326ec6f088c0aaf85efa69d
Author:        Valentin Schneider <valentin.schneider@arm.com>
AuthorDate:    Wed, 13 Nov 2019 16:53:34 
Committer:     Ingo Molnar <mingo@kernel.org>
CommitterDate: Fri, 15 Nov 2019 11:02:19 +01:00

sched/uclamp: Fix overzealous type replacement

Some uclamp helpers had their return type changed from 'unsigned int' to
'enum uclamp_id' by commit:

  0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")

but it happens that some *actually* do return an unsigned int value. Those
are the helpers that return a utilization value: uclamp_rq_max_value() and
uclamp_eff_value(). Fix those up.

Note that this doesn't lead to any obj diff using a relatively recent
aarch64 compiler (8.3-2019.03). The current code of e.g. uclamp_eff_value()
already figures out that the return value is 11 bits (bits_per(1024)) and
doesn't seem to do anything funny. I'm still marking this as fixing the
above commit to be on the safe side.

Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Qais Yousef <qais.yousef@arm.com>
Cc: Dietmar.Eggemann@arm.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: patrick.bellasi@matbug.net
Cc: qperret@google.com
Cc: surenb@google.com
Cc: tj@kernel.org
Cc: vincent.guittot@linaro.org
Fixes: 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values")
Link: https://lkml.kernel.org/r/20191113165334.14291-1-valentin.schneider@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/sched/core.c  | 4 ++--
 kernel/sched/sched.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 44123b4..a4f76d3 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -853,7 +853,7 @@ static inline void uclamp_idle_reset(struct rq *rq, enum uclamp_id clamp_id,
 }
 
 static inline
-enum uclamp_id uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id,
+unsigned int uclamp_rq_max_value(struct rq *rq, enum uclamp_id clamp_id,
 				   unsigned int clamp_value)
 {
 	struct uclamp_bucket *bucket = rq->uclamp[clamp_id].bucket;
@@ -918,7 +918,7 @@ uclamp_eff_get(struct task_struct *p, enum uclamp_id clamp_id)
 	return uc_req;
 }
 
-enum uclamp_id uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id)
+unsigned int uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id)
 {
 	struct uclamp_se uc_eff;
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index c8870c5..49ed949 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2309,7 +2309,7 @@ static inline void cpufreq_update_util(struct rq *rq, unsigned int flags) {}
 #endif /* CONFIG_CPU_FREQ */
 
 #ifdef CONFIG_UCLAMP_TASK
-enum uclamp_id uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id);
+unsigned int uclamp_eff_value(struct task_struct *p, enum uclamp_id clamp_id);
 
 static __always_inline
 unsigned int uclamp_util_with(struct rq *rq, unsigned int util,

^ permalink raw reply related	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2019-11-15 18:13 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-13 16:53 [PATCH] sched/uclamp: Fix overzealous type replacement Valentin Schneider
2019-11-14 20:28 ` Qais Yousef
2019-11-15  0:05   ` Valentin Schneider
2019-11-15  9:05     ` Qais Yousef
2019-11-15  8:12 ` Vincent Guittot
2019-11-15  9:09   ` Qais Yousef
2019-11-15  9:55   ` Valentin Schneider
2019-11-15 18:13 ` [tip: sched/urgent] " tip-bot2 for Valentin Schneider

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.