| Bug #79652 | Suspicious padding in srv_conc_t | ||
|---|---|---|---|
| Submitted: | 15 Dec 2015 19:17 | Modified: | 27 Aug 2018 11:56 |
| Reporter: | Alexey Kopytov (OCA) | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: InnoDB storage engine | Severity: | S5 (Performance) |
| Version: | 5.7 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[27 Jul 2018 11:56]
MySQL Verification Team
Hi Kaamos, my dear friend, Thank you for your report. I can fully see your problem. I would like to hear opinion on the solution(s). Do you think that this definition would be OK: char pad[64]; Or would this one be sufficient: char pad[64 - sizeof(lint)]; Many thanks in advance.
[28 Aug 2018 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".

Description: The srv_conc_t is declared in srv0conc.cc as follows: /** Variables tracking the active and waiting threads. */ struct srv_conc_t { char pad[64 - (sizeof(ulint) + sizeof(lint))]; /** Number of transactions that have declared_to_be_inside_innodb set. It used to be a non-error for this value to drop below zero temporarily. This is no longer true. We'll, however, keep the lint datatype to add assertions to catch any corner cases that we may have missed. */ volatile lint n_active; /** Number of OS threads waiting in the FIFO for permission to enter InnoDB */ volatile lint n_waiting; }; Since there's only one global variable of the srv_conc_t type (srv_conc), the purpose of pad member variable is unclear. One possible purpose is preventing neighboring global variables like srv_thread_concurrency from sharing the cache line with other members of srv_conc. But the chosen size of the padding does not actually guarantee that (consider a case when srv_thread_concurrency is located at the start of a cache line -- it will share the cache line with the n_active variable). Another possible reason is preventing cache line sharing between the n_active and n_waiting structure members, but then again, the padding size does not actually guarantee that (consider a case when srv_conc is located at the start of a cache line). How to repeat: Code analysis.