Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.6, 10.7(EOL), 10.8(EOL)
Description
The MDEV-26769 implementation of memory transactions may invoke a system call within a memory transaction if a page latch is not available in buf_page_get_zip().
In the Intel TSX-NI implementation (CPUID flag rtm), system calls will lead to the memory transaction being aborted, and there should be no correctness problem. The POWER v2.07 Hardware Transactional Memory allows memory transactions to execute system calls with some limitations, but our implementation assumes that no system calls will be executed as part of a memory transaction.
Furthermore, many memory transactions contain read-modify-write operations, such as std::atomic::fetch_add(). Inside memory transactions, plain loads and stores would work equally well and could result in more efficient code.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
MDEV-27956 hardware lock elision on s390x / ppc64 detection improvements
-
- Closed
-
Activity
bb-10.6-MDEV-28137, origin/bb-10.6-MDEV-28137 531516688fe8894b477b55664e188bb10f5a48de 2022-03-21T11:49:18+02:00
|
behaved well in RQG testing on boxes where the CPU model does
|
- support "rtm" Server error log message "[Note] InnoDB: Using transactional memory"
|
- not support rtm
|
Performance testing by axel showed a small consistent regression and a somewhat worse ratio of tx-abort to tx-start events. I implemented a reduced version, only modifying the rarely executed functions buf_page_get_zip() and buf_page_init_for_read(). The latter change should benefit any CPU, because some read-modify-write updates of block descriptor state will be removed.
POWER note, the original capability test was for transactions to be suspended in syscalls. Without this it will tabort on syscalls like Intel. So if the syscalls in `buf_page_get_zip` are executed, is there a correctness problem? After that its determining if the abort condition is rare enough for there to be a performance gain.