Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1601623 > unrolled thread

Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

Started byPatrick Bellasi <patrick.bellasi@arm.com>
First post2017-03-15 19:20 +0100
Last post2017-03-15 19:20 +0100
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE  enter Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-15 19:20 +0100

#1601623 — Re: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

FromPatrick Bellasi <patrick.bellasi@arm.com>
Date2017-03-15 19:20 +0100
SubjectRe: [PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter
Message-ID<tllGG-2YN-25@gated-at.bofh.it>
On 06-Mar 09:29, Steven Rostedt wrote:
> On Fri, 3 Mar 2017 09:11:25 +0530
> Viresh Kumar <viresh.kumar@linaro.org> wrote:
> 
> > On 02-03-17, 15:45, Patrick Bellasi wrote:
> > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > index e2ed46d..739b29d 100644
> > > --- a/include/linux/sched.h
> > > +++ b/include/linux/sched.h
> > > @@ -3653,6 +3653,7 @@ static inline unsigned long rlimit_max(unsigned int limit)
> > >  #define SCHED_CPUFREQ_RT	(1U << 0)
> > >  #define SCHED_CPUFREQ_DL	(1U << 1)
> > >  #define SCHED_CPUFREQ_IOWAIT	(1U << 2)
> > > +#define SCHED_CPUFREQ_IDLE	(1U << 3)
> > >  
> > >  #define SCHED_CPUFREQ_RT_DL	(SCHED_CPUFREQ_RT | SCHED_CPUFREQ_DL)
> > >  
> > > diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
> > > index fd46593..084a98b 100644
> > > --- a/kernel/sched/cpufreq_schedutil.c
> > > +++ b/kernel/sched/cpufreq_schedutil.c
> > > @@ -281,6 +281,12 @@ static void sugov_update_shared(struct update_util_data *hook, u64 time,
> > >  
> > >  	raw_spin_lock(&sg_policy->update_lock);
> > >  
> > > +	/* CPU is entering IDLE, reset flags without triggering an update */
> > > +	if (flags & SCHED_CPUFREQ_IDLE) {  
> > 
> > Will "flags == SCHED_CPUFREQ_IDLE" generate better assembly ?
> > 
> 
> Even if it does, a bit check and an equal check are pretty negligible
> in difference wrt execution time. I would choose whatever is the most
> readable to humans.
> 
>  flags == SCHED_CPUFREQ_IDLE
> 
> will tell me (as a reviewer) that we expect no other flag to be set.
> 
>  flags & SCHED_CPUFREQ_IDLE
> 
> will tell me that we only care about the IDLE flag.
> 
> Which ever is the more meaningful is what should be used.

Agree on the approach, whenever not silly code should be written to be
easy to understand from other humans.

Here the intent is "whatever flags you set, if the IDLE one is set" we
assume we are entering idle. Thus, to me the current version is easier
to understand without being "overkilling" in its semantics.

Cheers Patrick

-- 
#include <best/regards.h>

Patrick Bellasi

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web