Re: [PATCH 0/3] Add new ptrace request macros on PowerPC

[Michael Neuling <mikey@neuling.org>]

[-- Attachment #1: Type: text/plain, Size: 3581 bytes --]

How is it causing the problem?

Mikey

On 29 Apr 2014 17:02, "Anshuman Khandual" <khandual@linux.vnet.ibm.com>
wrote:
>
> On 04/02/2014 03:02 PM, Anshuman Khandual wrote:
> > On 04/02/2014 12:32 PM, Anshuman Khandual wrote:
> >>      This patch series adds new ELF note sections which are used to
> >> create new ptrace request macros for various transactional memory and
> >> miscellaneous registers on PowerPC. Please find the test case
exploiting
> >> the new ptrace request macros and it's results on a POWER8 system.
> >>
> >> RFC: https://lkml.org/lkml/2014/4/1/292
> >>
> >> ============================== Results ==============================
> >> -------TM specific SPR------
> >> TM TFHAR: 100009dc
> >> TM TEXASR: de000001ac000001
> >> TM TFIAR: c00000000003f386
> >> TM CH ORIG_MSR: 900000050000f032
> >> TM CH TAR: 6
> >> TM CH PPR: c000000000000
> >> TM CH DSCR: 1
> >> -------TM checkpointed GPR-----
> >> TM CH GPR[0]: 1000097c
> >> TM CH GPR[1]: 5
> >> TM CH GPR[2]: 6
> >> TM CH GPR[7]: 1
> >> TM CH NIP: 100009dc
> >> TM CH LINK: 1000097c
> >> TM CH CCR: 22000422
> >> -------TM running GPR-----
> >> TM RN GPR[0]: 1000097c
> >> TM RN GPR[1]: 7
> >> TM RN GPR[2]: 8
> >> TM RN GPR[7]: 5
> >> TM RN NIP: 100009fc
> >> TM RN LINK: 1000097c
> >> TM RN CCR: 2000422
> >> -------TM running FPR-----
> >> TM RN FPR[0]: 1002d3a3780
> >> TM RN FPR[1]: 7
> >> TM RN FPR[2]: 8
> >> TM RN FPSCR: 0
> >> -------TM checkpointed FPR-----
> >> TM CH FPR[0]: 1002d3a3780
> >> TM CH FPR[1]: 5
> >> TM CH FPR[2]: 6
> >> TM CH FPSCR: 0
> >> -------Running miscellaneous registers-------
> > TM RN DSCR: 0
> >
> > There is a problem in here which I forgot to mention. The running DSCR
value
> > comes from thread->dscr component of the target process. While we are
inside the
> > transaction (which is the case here as we are stuck at "b ."
instruction and
> > have not reached TEND) thread->dscr should have the running value of
the DSCR
> > register at that point of time. Here we expect the DSCR value to be 5
instead
> > of 0 as shown in the output above. During the tests when I moved the "b
." after
> > TEND, the thread->dscr gets the value of 5 while all check pointed reg
values are
> > thrown away. I believe there is some problem in the way thread->dscr
context
> > is saved away inside the TM section. Will look into this problem
further and
> > keep informed.
>
> Reason behind this inconsistent DSCR register value is because of the
following commit
> where the kernel reverts the DSCR register into a default value to avoid
running with
> the user set value for a long time, thus preventing any potential
performance degradation.
> Same reason applies to the PPR register as well. So its not a problem but
an expected
> behaviour.
>
> commit e9bdc3d6143d1c4b8d8ce5231fc958268331f983
> Author: Michael Neuling <mikey@neuling.org>
> Date:   Thu Sep 26 13:29:09 2013 +1000
>
>     powerpc/tm: Switch out userspace PPR and DSCR sooner
>
>     When we do a treclaim or trecheckpoint we end up running with
userspace
>     PPR and DSCR values.  Currently we don't do anything special to avoid
>     running with user values which could cause a severe performance
>     degradation.
>
>     This patch moves the PPR and DSCR save and restore around treclaim and
>     trecheckpoint so that we run with user values for a much shorter
period.
>     More care is taken with the PPR as it's impact is greater than the
DSCR.
>
>     This is similar to user exceptions, where we run HTM_MEDIUM early to
>     ensure that we don't run with a userspace PPR values in the kernel.
>

[-- Attachment #2: Type: text/html, Size: 4832 bytes --]