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
next prev parent 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 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).