linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Gautham R Shenoy <ego@linux.vnet.ibm.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org,
	"Gautham R . Shenoy" <ego@linux.vnet.ibm.com>,
	"Shreyas B . Prabhu" <shreyas@linux.vnet.ibm.com>,
	Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Subject: Re: [PATCH 08/14] powerpc/64s: idle avoid SRR usage in idle sleep/wake paths
Date: Tue, 13 Jun 2017 15:55:53 +0530	[thread overview]
Message-ID: <20170613102553.GJ10921@in.ibm.com> (raw)
In-Reply-To: <20170611235835.7400-9-npiggin@gmail.com>

Hi Nick,

On Mon, Jun 12, 2017 at 09:58:29AM +1000, Nicholas Piggin wrote:
> Idle code now always runs at the 0xc... effective address whether
> in real or virtual mode. This means rfid can be ditched, along
> with a lot of SRR manipulations.
> 
> In the wakeup path, carry SRR1 around in r12. Use mtmsrd to change
> MSR states as required.
> 
> This also balances the return prediction for the idle call, by
> doing blr rather than rfid to return to the idle caller.
> 
> On POWER9, 2-process context switch on different cores, with snooze
> disabled, increases performance by 2%.
> ---
>  arch/powerpc/kernel/exceptions-64s.S    |  1 +
>  arch/powerpc/kernel/idle_book3s.S       | 57 +++++++++++++++------------------
>  arch/powerpc/kvm/book3s_hv_rmhandlers.S |  8 ++++-
>  3 files changed, 33 insertions(+), 33 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index fec7c933d095..c3d0aef089a7 100644
> --- a/arch/powerpc/kernel/idle_book3s.S
> +++ b/arch/powerpc/kernel/idle_book3s.S
> @@ -148,12 +147,8 @@ pnv_powersave_common:
>  	 * the MMU context to the guest.
>  	 */
>  	LOAD_REG_IMMEDIATE(r7, MSR_IDLE)
> -	li	r6, MSR_RI
> -	andc	r6, r9, r6
> -	mtmsrd	r6, 1		/* clear RI before setting SRR0/1 */
> -	mtspr	SPRN_SRR0, r4
> -	mtspr	SPRN_SRR1, r7
> -	rfid
> +	mtmsrd	r7,0
> +	bctr

So at this point we need to transition from virtual to real mode as
the comment in pnv_enter_arch207_idle_mode expects us to. Which is
being performed by mtmsrd here. Then we jump to the function via
bctr. So, in this patch we are using two instructions to modify the
MSR and the PC, while earlier the rfid would update these atomically.

Does forgoing atomicity have any risk? I am asking this because
historically we have modified IR/DR bits in the MSR via rfid
mechanism.
--
Thanks and Regards
gautham.

  reply	other threads:[~2017-06-13 10:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-11 23:58 [PATCH 00/14 v2] idle performance improvements Nicholas Piggin
2017-06-11 23:58 ` [PATCH 01/14] powerpc/64s: idle move soft interrupt mask logic into C code Nicholas Piggin
2017-06-12  8:37   ` Gautham R Shenoy
2017-06-12 14:46     ` Nicholas Piggin
2017-06-13  4:28       ` Gautham R Shenoy
2017-06-11 23:58 ` [PATCH 02/14] powerpc/64s: idle hotplug lazy-irq simplification Nicholas Piggin
2017-06-11 23:58 ` [PATCH 03/14] powerpc/64s: idle provide a default idle for POWER9 Nicholas Piggin
2017-06-12  8:53   ` Gautham R Shenoy
2017-06-12 14:46     ` Nicholas Piggin
2017-06-11 23:58 ` [PATCH 04/14] powerpc/64s: idle process interrupts from system reset wakeup Nicholas Piggin
2017-06-12  9:41   ` Gautham R Shenoy
2017-06-12 14:51     ` Nicholas Piggin
2017-06-11 23:58 ` [PATCH 05/14] powerpc/64s: msgclr when handling doorbell exceptions Nicholas Piggin
2017-06-12 14:38   ` Gautham R Shenoy
2017-06-11 23:58 ` [PATCH 06/14] powerpc/64s: interrupt replay balance the return branch predictor Nicholas Piggin
2017-06-12 14:41   ` Gautham R Shenoy
2017-06-13  9:51   ` Michael Ellerman
2017-06-13 11:09     ` Nicholas Piggin
2017-06-11 23:58 ` [PATCH 07/14] powerpc/64s: idle branch to handler with virtual mode offset Nicholas Piggin
2017-06-11 23:58 ` [PATCH 08/14] powerpc/64s: idle avoid SRR usage in idle sleep/wake paths Nicholas Piggin
2017-06-13 10:25   ` Gautham R Shenoy [this message]
2017-06-13 10:45     ` Nicholas Piggin
2017-06-11 23:58 ` [PATCH 09/14] powerpc/64s: idle hmi wakeup is unlikely Nicholas Piggin
2017-06-12 15:03   ` Gautham R Shenoy
2017-06-11 23:58 ` [PATCH 10/14] powerpc/64s: cpuidle set polling before enabling irqs Nicholas Piggin
2017-06-12 15:10   ` Gautham R Shenoy
2017-06-12 15:20     ` Nicholas Piggin
2017-06-11 23:58 ` [PATCH 11/14] powerpc/64s: cpuidle read mostly for common globals Nicholas Piggin
2017-06-12 15:30   ` Gautham R Shenoy
2017-06-12 17:50     ` Vaidyanathan Srinivasan
2017-06-11 23:58 ` [PATCH 12/14] powerpc/64s: cpuidle no memory barrier after break from idle Nicholas Piggin
2017-06-12 17:48   ` Vaidyanathan Srinivasan
2017-06-13 12:47     ` Nicholas Piggin
2017-06-11 23:58 ` [PATCH 13/14] powerpc/64: runlatch CTRL[RUN] set optimisation Nicholas Piggin
2017-06-12 17:11   ` Vaidyanathan Srinivasan
2017-06-13 10:04     ` Michael Ellerman
2017-06-13 11:56       ` Nicholas Piggin
2017-06-13 13:45       ` Benjamin Herrenschmidt
2017-06-14  3:34         ` Michael Ellerman
2017-06-11 23:58 ` [PATCH 14/14] powerpc/64s: idle runlatch switch is done with MSR[EE]=0 Nicholas Piggin
2017-06-12 17:00   ` Vaidyanathan Srinivasan
  -- strict thread matches above, loose matches on Subject: below --
2017-06-08 15:50 [PATCH 00/14] idle performance improvements Nicholas Piggin
2017-06-08 15:51 ` [PATCH 08/14] powerpc/64s: idle avoid SRR usage in idle sleep/wake paths Nicholas Piggin

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=20170613102553.GJ10921@in.ibm.com \
    --to=ego@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    --cc=shreyas@linux.vnet.ibm.com \
    --cc=svaidy@linux.vnet.ibm.com \
    /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).