linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: shilpa <shilpa.bhat@linux.vnet.ibm.com>
To: David Laight <David.Laight@ACULAB.COM>,
	Viresh Kumar <viresh.kumar@linaro.org>
Cc: Preeti U Murthy <preeti@linux.vnet.ibm.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v2] cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec
Date: Wed, 10 Sep 2014 12:27:13 +0530	[thread overview]
Message-ID: <540FF649.2090901@linux.vnet.ibm.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D174849AD@AcuExch.aculab.com>

On 09/01/2014 02:42 PM, David Laight wrote:
>> Yes unlikely() should cover the whole if statement...
> 
> Actually it probably shouldn't.
> You need to look at the generated code with each different set of 'unlikely()'
> to see how gcc processes them.
> In this case, if 'rebooting' is false you want to 'fall through' on a statically
> predicted 'not taken' branch. You don't ever care about the second clause.
> With an 'unlikely' covering the entire statement gcc could easily add a
> forwards conditional branch (that will be mis-predicted) for the 'rebooting' test.
> 
> (Yes, I spent a lot of time getting gcc to generate branches that were
> correctly statically predicted for some code where every cycle mattered.)
> 
> 	David
> 
Hi David,

The objdup with an 'unlikely()' covering the entire if statement is as follows:

 if (unlikely(rebooting && new_index != get_nominal_index()))
	return -EBUSY;

 1ac:   2f 89 00 00     cmpwi   cr7,r9,0   /* compare rebooting,0 */
 1b0:   40 de 00 4c     bne-    cr7,1fc <.powernv_cpufreq_target_index+0x7c>

 The '-' in the instruction bne- specifies an unlikely branch. So gcc has
 processed the first clause to be identified as an unlikely branch i.e,
 branch to <1fc> (to test the second clause) is unlikely on 'rebooting' not
 equal to 0.


 1b4:   1f ff 00 0c     mulli   r31,r31,12
 .
 . <--- Set the frequency and return --->
 .
 .
 1fc:   3d 22 00 00     addis   r9,r2,0  /* test the second clause */
 200:   3d 02 00 00     addis   r8,r2,0
 204:   81 49 00 00     lwz     r10,0(r9)
 208:   81 28 00 00     lwz     r9,0(r8)
 20c:   7d 29 50 50     subf    r9,r9,r10
 210:   7f 89 f8 00     cmpw    cr7,r9,r31 /* compare new_index,nominal_index */
 214:   41 9e ff a0     beq+     cr7,1b4 <.powernv_cpufreq_target_index+0x34>

 The '+' in the instruction beq+ specifies a likely branch. The second clause
 unlikely(new_index != get_nominal_index()) is processed to
 likely(new_index == get_nominal_index()).

 218:   38 60 ff f0     li      r3,-16  /* return -EBUSY */
 21c:   4b ff ff cc     b       1e8 <.powernv_cpufreq_target_index+0x68>

So unlikely() covering the entire statement will not lead to a branch mis-prediction
for the 'rebooting' test. Having unlikely to cover both 'rebooting' and  the second
clause we can avoid the branch miss prediction for the second clause. This is
advantageous for the code path powernv_cpufreq_target_index(policy,nominal_index)
which will be invoked by the reboot_notifier.

Thanks and Regards,
Shilpa

      reply	other threads:[~2014-09-10  6:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-28 14:06 [PATCH v2] cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec Shilpasri G Bhat
2014-08-29  0:03 ` Viresh Kumar
2014-09-01  5:18   ` Shilpa Bhat
2014-09-01  5:27     ` Viresh Kumar
2014-09-01  6:05       ` Shilpa Bhat
2014-09-01  9:12     ` David Laight
2014-09-10  6:57       ` shilpa [this message]

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=540FF649.2090901@linux.vnet.ibm.com \
    --to=shilpa.bhat@linux.vnet.ibm.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rjw@rjwysocki.net \
    --cc=viresh.kumar@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).