linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org,
	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: Mon, 6 Mar 2017 10:15:53 +0530	[thread overview]
Message-ID: <20170306044553.GE8206@vireshk-i7> (raw)
In-Reply-To: <1668614.4zDQWLsnmH@aspire.rjw.lan>

On 04-03-17, 01:11, Rafael J. Wysocki wrote:
> So one idea is that if SCHED_CPUFREQ_RT_DL is set in flags, we don't even
> need to start the loop which is quite a cost to simply notice that there's
> nothing to do.

Hmm. Isn't the probability of this flag being set, same for all CPUs in the
policy? If yes, then why do we need to handle the current CPU specially?

> Also I don't quite agree with adding an extra pair of integer multiplications
> to that loop just to get rid of the extra args.

But that should be cheap enough as we would be multiplying with 1 in one of them
and with 0 on the other.

Isn't that better then keeping same code at two places?

Also as I mentioned in the commit log, the number of extra comparisons for the
current CPU will be balanced if we have three CPUs in the policy and with every
other CPU in the policy, we will end up doing one comparison less. With
Quad-core policies, we reduce the number of comparisons by 1 and for octa-core
ones, we reduce it by 5.

-- 
viresh

  reply	other threads:[~2017-03-06  4:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-02  8:33 [PATCH 0/3] cupfreq: schedutil: Minor fix and cleanups Viresh Kumar
2017-03-02  8:33 ` [PATCH 1/3] cpufreq: schedutil: move cached_raw_freq to struct sugov_policy Viresh Kumar
2017-03-02 22:05   ` Rafael J. Wysocki
2017-03-03  3:07     ` Viresh Kumar
2017-03-02  8:33 ` [PATCH 2/3] cpufreq: schedutil: Pass sg_policy to get_next_freq() Viresh Kumar
2017-03-02  8:33 ` [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared() Viresh Kumar
2017-03-04  0:03   ` Rafael J. Wysocki
2017-03-04  0:11     ` Rafael J. Wysocki
2017-03-06  4:45       ` Viresh Kumar [this message]
2017-03-06 12:24         ` Rafael J. Wysocki
2017-03-07 10:31           ` Viresh Kumar
2017-03-07 13:19             ` Rafael J. Wysocki
2017-03-08  4:18               ` Viresh Kumar
2017-03-08 10:50                 ` Rafael J. Wysocki
2017-03-08 11:15                   ` Viresh Kumar
2017-03-08 12:54                     ` Rafael J. Wysocki

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=20170306044553.GE8206@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=vincent.guittot@linaro.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).