[PATCH 0/2] Enable MSR_TM lazily

[Nicholas Piggin]

Cc'ing Carlos

On Wed, 14 Sep 2016 18:02:14 +1000
Cyril Bur <cyrilbur at gmail.com> wrote:

> 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.
> 
> 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.
> 
> 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!

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?

How common it is for glibc to be built with elision?

We should probably be testing PPC_FEATURE2_HTM_NOSC to skip the
tabort.

(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?)

Thanks,
Nick