| Bug #62425 | improve CPU cache performance for trx_t | ||
|---|---|---|---|
| Submitted: | 13 Sep 2011 19:30 | Modified: | 15 Nov 2011 0:02 |
| Reporter: | Mark Callaghan | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: InnoDB Plugin storage engine | Severity: | S5 (Performance) |
| Version: | 5.1.52 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[13 Sep 2011 19:30]
Mark Callaghan
[13 Sep 2011 21:33]
Sunny Bains
What is the difference without pre-allocation? ie. only rearranging the fields in trx_t.
[13 Sep 2011 22:54]
Mark Callaghan
I don't know. Most of the cache benefit comes from reordering the fields. Pre-allocating avoids mem allocation over while holding kernel_mutex (I think).
[13 Sep 2011 23:23]
Sunny Bains
Yes, that much I figured out but I was keen to see the numbers around the cache benefits. I didn't see any difference in my tests when I rearranged the fields in 5.6. If the numbers are compelling then I would like to make this change in 5.6 to start with. The trx_t layout is a little different in 5.6 compared to previous versions. In 5.6 the trx_t allocation is done outside of any mutex.
[14 Sep 2011 4:09]
Valeriy Kravchuk
Looks like InnoDB team is waiting for numbers with re-ordering alone to make final decision...
[14 Oct 2011 23: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".
[15 Nov 2011 7: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".
