[MDEV-28137] Some memory transactions are unnecessarily complex Created: 2022-03-21 Updated: 2022-03-24 Resolved: 2022-03-24 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.6, 10.7, 10.8 |
| Fix Version/s: | 10.6.8, 10.7.4, 10.8.3, 10.9.1 |
| Type: | Bug | Priority: | Major |
| Reporter: | Marko Mäkelä | Assignee: | Marko Mäkelä |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | performance | ||
| Issue Links: |
|
||||||||||||
| Description |
|
The 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. |
| Comments |
| Comment by Daniel Black [ 2022-03-22 ] | ||||
|
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. | ||||
| Comment by Daniel Black [ 2022-03-22 ] | ||||
|
review added on https://github.com/mariaDB/server/commit/531516688fe8894b477b55664e188bb10f5a48de | ||||
| Comment by Matthias Leich [ 2022-03-23 ] | ||||
|
| ||||
| Comment by Marko Mäkelä [ 2022-03-24 ] | ||||
|
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. |