Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Lists linaro-kernel <linaro-kernel@lists.linaro.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()
Date: Wed, 8 Mar 2017 09:48:23 +0530	[thread overview]
Message-ID: <20170308041823.GB4526@vireshk-i7> (raw)
In-Reply-To: <CAJZ5v0itZo-tybgz2p49VxkGzFL9EZBB-4aZg6R5sthVrBiAYQ@mail.gmail.com>

On 07-03-17, 14:19, Rafael J. Wysocki wrote:
> On Tue, Mar 7, 2017 at 11:31 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> > Why do you think so? I thought all CPU in the policy can have the RT/DL flag set
> > and the probability of all of them is just the same.
> 
> Well, yes, but if the current CPU has that flag set already, we surely
> don't need to check the other ones in the policy?

That's true for every other CPU in policy too..

> >> So to the point, the code was written this way on purpose and not just
> >> by accident as your changelog suggests and
> >
> > I didn't wanted to convey that really and I knew that it was written on purpose.
> >
> >> if you want to change it, you need numbers.
> >
> > What kind of numbers can we get for such a change ? I tried to take the running
> > average of the time it takes to execute this routine over 10000 samples, but it
> > varies a lot even with the same build. Any tests like hackbench, etc wouldn't be
> > of any help as well.
> 
> So why do you think it needs to be changed, but really?
> 
> Is that because it is particularly hard to follow or similar?

Just that I didn't like keeping the same code at two places (outside
and inside the loop) and the benefit it has.

Anyway, its not straight forward to get any numbers supporting my
argument. I can claim improvement only theoretically by comparing the
number of comparisons that we may end up doing for quad or octa core
policies. Lets abandon this patch as I failed to convince you :)

Thanks for applying the other two patches though.

Cheers.

-- 
viresh