From: Michael Neuling <mikey@neuling•org>
To: Nicholas Piggin <npiggin@gmail•com>,
Cyril Bur <cyrilbur@gmail•com>,
Carlos Eduardo Seo <cseo@linux•vnet.ibm.com>
Cc: linuxppc-dev@lists•ozlabs.org, mpe@ellerman•id.au,
wei.guo.simon@gmail•com, anton@samba•org
Subject: Re: [PATCH 0/2] Enable MSR_TM lazily
Date: Wed, 14 Sep 2016 21:46:39 +1000 [thread overview]
Message-ID: <1473853599.22937.85.camel@neuling.org> (raw)
In-Reply-To: <20160914212824.4936a9a2@roar.ozlabs.ibm.com>
On Wed, 2016-09-14 at 21:28 +1000, Nicholas Piggin wrote:
> Cc'ing Carlos
>=20
> On Wed, 14 Sep 2016 18:02:14 +1000
> Cyril Bur <cyrilbur@gmail•com> wrote:
>=20
> >=20
> > Currently the kernel checks to see if the hardware is transactional
> > memory capable and always enables the MSR_TM bit. The problem with
> > this is that the TM related SPRs become available to userspace,
> > requiring them to be switched between processes. It turns out these
> > SPRs are expensive to read and write and if a thread doesn't use TM
> > (or worse yet isn't even TM aware) then context switching incurs this
> > penalty for nothing.
> >=20
> > The solution here is to leave the MSR_TM bit disabled and enable it
> > more 'on demand'. Leaving MSR_TM disabled cause a thread to take a
> > facility unavailable fault if and when it does decide to use TM. As
> > with recent updates to the FPU, VMX and VSX units the MSR_TM bit will
> > be enabled upon taking the fault and left on for some time afterwards
> > as the assumption is that if a thread used TM ones it may well use it
> > again. The kernel will turn the MSR_TM bit off after some number of
> > context switches of that thread.
> >=20
> > Performance numbers haven't been completely gathered as yet but early
> > runs of tools/testing/selftests/powerpc/benchmarks/context_switch
> > (which doesn't use TM) yields a jump from ~160000 switches per second
> > to ~180000 switches per second with patch 3/3 applied.
> Cool!
>=20
> Question: glibc when built with lock elision seems like it will
> execute tabort. before every syscall, to work around old kernel
> behaviour. That's always going to fault TM on, isn't it?
I think we might be able to detect this case in the kernel. If it's a tabor=
t
that's trapped on, we can't have been transactional. =C2=A0Hence we can saf=
ely PC+=3D4
and leave off TM off.=C2=A0
It would cost us a get_user(inst, regs->nip); but it might be worth it for =
this
special but common case.
> How common it is for glibc to be built with elision?
IIRC Ubuntu uses it on 16.04 (and maybe 15.10).
> We should probably be testing PPC_FEATURE2_HTM_NOSC to skip the
> tabort.
Agree, that would be idea. Binary patching glic at runtime.
> (BTW, this is a pretty good writeup, would you consider adding
> a bit more of it to patch 2 so it gets into the changelog?)
Agreed.
Mikey
next prev parent reply other threads:[~2016-09-14 11:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 8:02 [PATCH 0/2] Enable MSR_TM lazily Cyril Bur
2016-09-14 8:02 ` [PATCH 1/2] powerpc: tm: Add TM Unavailable Exception Cyril Bur
2016-10-05 2:36 ` [1/2] " Michael Ellerman
2016-09-14 8:02 ` [PATCH 2/2] powerpc: tm: Enable transactional memory (TM) lazily for userspace Cyril Bur
2016-09-19 4:47 ` Simon Guo
2016-09-19 5:26 ` Cyril Bur
2016-09-14 11:28 ` [PATCH 0/2] Enable MSR_TM lazily Nicholas Piggin
2016-09-14 11:46 ` Michael Neuling [this message]
2016-09-14 12:12 ` Nicholas Piggin
2016-09-14 12:17 ` Michael Neuling
2016-09-14 14:10 ` Carlos Eduardo Seo
2016-09-15 3:59 ` 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=1473853599.22937.85.camel@neuling.org \
--to=mikey@neuling$(echo .)org \
--cc=anton@samba$(echo .)org \
--cc=cseo@linux$(echo .)vnet.ibm.com \
--cc=cyrilbur@gmail$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mpe@ellerman$(echo .)id.au \
--cc=npiggin@gmail$(echo .)com \
--cc=wei.guo.simon@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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