Enable MSR_TM lazily

If the kernel disables transactional memory (TM) and userspace still tries TM related actions (TM instructions or TM SPR accesses) TM aware hardware will cause the kernel to take a facility unavailable exception.

Add checks for the exception being caused by illegal TM access in userspace.

Signed-off-by Cyril Bur <[email protected]>

arch/powerpc/kernel/process.c +0 -1

@@ -954,8 +963,16 @@ static inline void __switch_to_tm(struct task_struct *prev,
 		struct task_struct *new)
 {
 	if (cpu_has_feature(CPU_FTR_TM)) {
-		tm_enable();

Quoted 8 lines · Cyril Bur

arch/powerpc/kernel/process.c +0 -2

@@ -954,8 +963,16 @@ static inline void __switch_to_tm(struct
 task_struct *prev,
  		struct task_struct *new)
  {
  	if (cpu_has_feature(CPU_FTR_TM)) {
-		tm_enable();
-		tm_reclaim_task(prev);

arch/powerpc/kernel/process.c static inline void __switch_to_tm(struct · line 976

Quoted 10 lines

arch/powerpc/kernel/process.c +9 -0

+		if (tm_enabled(prev) || tm_enabled(new))
+			tm_enable();
+
+		if (tm_enabled(prev)) {
+			prev->thread.load_tm++;
+			tm_reclaim_task(prev);
+			if (!MSR_TM_ACTIVE(prev->thread.regs->msr) 
 && prev->thread.load_tm == 0)
+				prev->thread.regs->msr &= ~MSR_TM;
+		}

Hi Cyril,

If MSR_TM_ACTIVE(), is it better to reset load_tm to 0? Other looks good to me.

Thanks,
- Simon

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.

Cc'ing Carlos
=20
On Wed, 14 Sep 2016 18:02:14 +1000
Cyril Bur <[email protected]> wrote:
=20

Quoted 14 lines

=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

Quoted 8 lines

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?

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

Quoted 27 lines · Nicholas Piggin

Cc'ing Carlos
=20
On Wed, 14 Sep 2016 18:02:14 +1000
Cyril Bur <[email protected]> wrote:
=20

Quoted 22 lines

=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. =20

Quoted 5 lines

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? =20

=20
I think we might be able to detect this case in the kernel. If it's a tab=

that's trapped on, we can't have been transactional. =C2=A0Hence we can s=

and leave off TM off.=C2=A0
=20
It would cost us a get_user(inst, regs->nip); but it might be worth it fo=

special but common case.

Quoted 1 line

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

=20
IIRC Ubuntu uses it on 16.04 (and maybe 15.10).

Quoted 2 lines

We should probably be testing PPC_FEATURE2_HTM_NOSC to skip the tabort. =20

=20
Agree, that would be idea. Binary patching glic at runtime.

Quoted 6 lines · On Wed, 14 Sep 2016 21:46:39 +1000 Michael Neuling <[email protected]> wrote:

Quoted 3 lines · Nicholas Piggin

Cc'ing Carlos

On Wed, 14 Sep 2016 18:02:14 +1000

I think we might be able to detect this case in the kernel. If it's a

Quoted 1 line

that's trapped on, we can't have been transactional. Hence we can

Quoted 3 lines

and leave off TM off.

It would cost us a get_user(inst, regs->nip); but it might be worth it

Quoted 1 line

special but common case.

That would take an extra trap for every syscall, I think.

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

Quoted 3 lines · Nicholas Piggin

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

Not that common. We have it built with TLE support in Ubuntu (starting in 15.04), SLES 12 (since SP2) and AT 9.0-0.

However, it is only enabled by default in Ubuntu. For SLES and AT 9.0, the user has to set an env var to enable it (it's a hack).

There is some work upstream to add a tunables framework to glibc. That will allow us to properly provide a way to users enable/disable TLE as they wish. That patch is almost in, and as soon as it's committed, we'll start working on the tunable for TLE.