* Breno Leitao: > This patchset for the hardware transactional memory (TM) subsystem > aims to avoid spending a lot of time on TM suspended mode in kernel > space. It basically changes where the reclaim/recheckpoint will be > executed.
I assumed that we want to abort on every system call these days? We have this commit in glibc: commit f0458cf4f9ff3d870c43b624e6dccaaf657d5e83 Author: Adhemerval Zanella <adhemerval.zane...@linaro.org> Date: Mon Aug 27 09:42:50 2018 -0300 powerpc: Only enable TLE with PPC_FEATURE2_HTM_NOSC Linux from 3.9 through 4.2 does not abort HTM transaction on syscalls, instead it suspend and resume it when leaving the kernel. The side-effects of the syscall will always remain visible, even if the transaction is aborted. This is an issue when transaction is used along with futex syscall, on pthread_cond_wait for instance, where the futex call might succeed but the transaction is rolled back leading the pthread_cond object in an inconsistent state. Glibc used to prevent it by always aborting a transaction before issuing a syscall. Linux 4.2 also decided to abort active transaction in syscalls which makes the glibc workaround superfluous. Worse, glibc transaction abortion leads to a performance issue on recent kernels where the HTM state is saved/restore lazily (v4.9). By aborting a transaction on every syscalls, regardless whether a transaction has being initiated before, GLIBS makes the kernel always save/restore HTM state (it can not even lazily disable it after a certain number of syscall iterations). Because of this shortcoming, Transactional Lock Elision is just enabled when it has been explicitly set (either by tunables of by a configure switch) and if kernel aborts HTM transactions on syscalls (PPC_FEATURE2_HTM_NOSC). It is reported that using simple benchmark [1], the context-switch is about 5% faster by not issuing a tabort in every syscall in newer kernels. I wonder how the new TM model interacts with the assumption we currently have in glibc. Thanks, Florian