Re: [RFC PATCH v2 00/14] New TM Model

* 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 [off-list ref]
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