All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Guo <wei.guo.simon@gmail.com>
To: Cyril Bur <cyrilbur@gmail.com>
Cc: linuxppc-dev@lists.ozlabs.org, mikey@neuling.org, anton@samba.org
Subject: Re: [PATCH v3 19/21] powerpc: tm: Always use fp_state and vr_state to store live registers
Date: Fri, 19 Aug 2016 12:04:43 +0800	[thread overview]
Message-ID: <20160819040442.GA3387@simonLocalRHEL7.x64> (raw)
In-Reply-To: <20160817034323.23053-20-cyrilbur@gmail.com>

On Wed, Aug 17, 2016 at 01:43:21PM +1000, Cyril Bur wrote:
> There is currently an inconsistency as to how the entire CPU register
> state is saved and restored when a thread uses transactional memory
> (TM).
> 
> Using transactional memory results in the CPU having duplicated
> (almost all) of its register state. This duplication results in a set
> of registers which can be considered 'live', those being currently
> modified by the instructions being executed and another set that is
> frozen at a point in time.
> 
> On context switch, both sets of state have to be saved and (later)
> restored. These two states are often called a variety of different
> things. Common terms for the state which only exists after has entered
> a transaction (performed a TBEGIN instruction) in hardware is the
> 'transactional' or 'speculative'.
> 
> Between a TBEGIN and a TEND or TABORT (or an event that causes the
> hardware to abort), regardless of the use of TSUSPEND the
> transactional state can be referred to as the live state.
> 
> The second state is often to referred to as the 'checkpointed' state
> and is a duplication of the live state when the TBEGIN instruction is
> executed. This state is kept in the hardware and will be rolled back
> to on transaction failure.
> 
> Currently all the registers stored in pt_regs are ALWAYS the live
> registers, that is, when a thread has transactional registers their
> values are stored in pt_regs and the checkpointed state is in
> ckpt_regs. A strange opposite is true for fp_state. When a thread is
> non transactional fp_state holds the live registers. When a thread
> has initiated a transaction fp_state holds the checkpointed state and
> transact_fp becomes the structure which holds the live state (at this
> point it is a transactional state). The same is true for vr_state
> 
> This method creates confusion as to where the live state is, in some
> circumstances it requires extra work to determine where to put the
> live state and prevents the use of common functions designed (probably
> before TM) to save the live state.
> 
> With this patch pt_regs, fp_state and vr_state all represent the
> same thing and the other structures [pending rename] are for
> checkpointed state.
> 
> Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Acked-by: Simon Guo <wei.guo.simon@gmail.com>

Thanks,
- Simon

  reply	other threads:[~2016-08-19  4:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17  3:43 [PATCH v3 00/21] Consistent TM structures Cyril Bur
2016-08-17  3:43 ` [PATCH v3 01/21] selftests/powerpc: Compile selftests against headers without AT_HWCAP2 Cyril Bur
2016-08-17  3:43 ` [PATCH v3 02/21] powerpc: Always restore FPU/VEC/VSX if hardware transactional memory in use Cyril Bur
2016-08-19  6:33   ` Michael Neuling
2016-08-23  0:57     ` Cyril Bur
2016-08-17  3:43 ` [PATCH v3 03/21] powerpc: Add check_if_tm_restore_required() to giveup_all() Cyril Bur
2016-08-19  6:40   ` Michael Neuling
2016-08-17  3:43 ` [PATCH v3 04/21] powerpc: Return the new MSR from msr_check_and_set() Cyril Bur
2016-08-17  3:53   ` Cyril Bur
2016-08-19  6:47   ` Michael Neuling
2016-08-17  3:43 ` [PATCH v3 05/21] powerpc: Never giveup a reclaimed thread when enabling kernel {fp, altivec, vsx} Cyril Bur
2016-08-17  3:43 ` [PATCH v3 06/21] powerpc: signals: Stop using current in signal code Cyril Bur
2016-08-17  4:31   ` kbuild test robot
2016-08-17  3:43 ` [PATCH v3 07/21] selftests/powerpc: Check for VSX preservation across userspace preemption Cyril Bur
2016-08-17  3:43 ` [PATCH v3 08/21] selftests/powerpc: Rework FPU stack placement macros and move to header file Cyril Bur
2016-08-17  3:43 ` [PATCH v3 09/21] selftests/powerpc: Move VMX stack frame macros " Cyril Bur
2016-08-17  3:43 ` [PATCH v3 10/21] selftests/powerpc: Introduce GPR asm helper " Cyril Bur
2016-08-17  3:43 ` [PATCH v3 11/21] selftests/powerpc: Add transactional memory defines Cyril Bur
2016-08-17  3:43 ` [PATCH v3 12/21] selftests/powerpc: Allow tests to extend their kill timeout Cyril Bur
2016-08-17  3:43 ` [PATCH v3 13/21] selftests/powerpc: Add TM tcheck helpers in C Cyril Bur
2016-08-17  3:43 ` [PATCH v3 14/21] selftests/powerpc: Check that signals always get delivered Cyril Bur
2016-08-17  3:43 ` [PATCH v3 15/21] selftests/powerpc: Add checks for transactional GPRs in signal contexts Cyril Bur
2016-08-17  3:43 ` [PATCH v3 16/21] selftests/powerpc: Add checks for transactional FPUs " Cyril Bur
2016-08-17  3:43 ` [PATCH v3 17/21] selftests/powerpc: Add checks for transactional VMXs " Cyril Bur
2016-08-17  3:43 ` [PATCH v3 18/21] selftests/powerpc: Add checks for transactional VSXs " Cyril Bur
2016-08-17  3:43 ` [PATCH v3 19/21] powerpc: tm: Always use fp_state and vr_state to store live registers Cyril Bur
2016-08-19  4:04   ` Simon Guo [this message]
2016-08-17  3:43 ` [PATCH v3 20/21] powerpc: tm: Rename transct_(*) to ck(\1)_state Cyril Bur
2016-08-17  3:43 ` [PATCH v3 21/21] powerpc: Remove do_load_up_transact_{fpu,altivec} Cyril Bur

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=20160819040442.GA3387@simonLocalRHEL7.x64 \
    --to=wei.guo.simon@gmail.com \
    --cc=anton@samba.org \
    --cc=cyrilbur@gmail.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.